Notices


Reply
Thread Tools
Posts: 245 | Thanked: 908 times | Joined on Feb 2012
#21
Originally Posted by z720 View Post
I'm facing "chroot: can't execute '/bin/sh': Operation not permitted"
with same image I manage to chroot on android ICS.

Any help?


Full log ~

[...]
chroot: can't execute '/bin/sh': Operation not permitted
Hmm...I just realized what the problem probably is.

Try opening a shell using the following (incredibly long) command, then launch the chroot:

opensh -c 'aegis-exec -c -a CAP::chown -a CAP::dac_override -a CAP::dac_read_search -a CAP::fowner -a CAP::fsetid -a CAP::kill -a CAP::setgid -a CAP::setuid -a CAP::setpcap -a CAP::linux_immutable -a CAP::net_bind_service -a CAP::net_broadcast -a CAP::net_admin -a CAP::net_raw -a CAP::ipc_lock -a CAP::ipc_owner -a CAP::sys_module -a CAP::sys_rawio -a CAP::sys_chroot -a CAP::sys_ptrace -a CAP::sys_pacct -a CAP::sys_admin -a CAP::sys_boot -a CAP::sys_nice -a CAP::sys_resource -a CAP::sys_time -a CAP::sys_tty_config -a CAP::mknod -a CAP::lease -a CAP::audit_write -a CAP::audit_control -a CAP::setfcap -a CAP::mac_override -a CAP::mac_admin sh'
 
Posts: 23 | Thanked: 11 times | Joined on Nov 2011
#22
Originally Posted by itsnotabigtruck View Post
Hmm...I just realized what the problem probably is.

Try opening a shell using the following (incredibly long) command, then launch the chroot:

opensh -c 'aegis-exec -c -a CAP::chown -a CAP::dac_override -a CAP::dac_read_search -a CAP::fowner -a CAP::fsetid -a CAP::kill -a CAP::setgid -a CAP::setuid -a CAP::setpcap -a CAP::linux_immutable -a CAP::net_bind_service -a CAP::net_broadcast -a CAP::net_admin -a CAP::net_raw -a CAP::ipc_lock -a CAP::ipc_owner -a CAP::sys_module -a CAP::sys_rawio -a CAP::sys_chroot -a CAP::sys_ptrace -a CAP::sys_pacct -a CAP::sys_admin -a CAP::sys_boot -a CAP::sys_nice -a CAP::sys_resource -a CAP::sys_time -a CAP::sys_tty_config -a CAP::mknod -a CAP::lease -a CAP::audit_write -a CAP::audit_control -a CAP::setfcap -a CAP::mac_override -a CAP::mac_admin sh'
Here is the error return

Chroot dir specified: /.debian
/home/user/MyDocs/bt5/bt5.img.ext4 specified in ~/.chroot
Mounting...
using image file: /home/user/MyDocs/bt5/bt5.img.ext4
fs type is ext4
Using ext4 file system
FATAL: Module ext4 not found.
mounting /home/user/MyDocs/bt5/bt5.img.ext4 on loop
.../home/user/MyDocs/bt5/bt5.img.ext4 mounted on loop0
.
..
...
....
/bin/qchroot: line 145: blkid: not found
/bin/qchroot: line 156: blkid: not found
Everything set up, running chroot...
chroot: can't execute '/bin/develsh': No such file or directory


Manually "chroot /.debian/ /bin/sh"
/ # chroot /.debian/ /bin/sh
chroot: can't execute '/bin/sh': Operation not permitted
 
Posts: 245 | Thanked: 908 times | Joined on Feb 2012
#23
OK, now do dmesg | tail -50 and post any Aegis error messages you see there.
 
Posts: 23 | Thanked: 11 times | Joined on Nov 2011
#24
Originally Posted by itsnotabigtruck View Post
OK, now do dmesg | tail -50 and post any Aegis error messages you see there.
here you are..

[15542.224365] credp: chroot: credential 0::21 not present in source SRC::9990006
[15542.224395] credp: chroot: credential 0::27 not present in source SRC::9990006
[15542.224456] credp: chroot: credential 0::32 not present in source SRC::9990006
[15542.224487] credp: chroot: credential 0::33 not present in source SRC::9990006
[15542.224517] Aegis: credp_kcheck failed 9990006 bash
[15542.224548] Aegis: bash verification failed (source origin check)
[15546.575714] credp: chroot: credential 0::1 not present in source SRC::9990006
[15546.575775] credp: chroot: credential 0::6 not present in source SRC::9990006
[15546.575805] credp: chroot: credential 0::7 not present in source SRC::9990006
[15546.575836] credp: chroot: credential 0::16 not present in source SRC::9990006
[15546.575866] credp: chroot: credential 0::17 not present in source SRC::9990006
[15546.575897] credp: chroot: credential 0::21 not present in source SRC::9990006
[15546.575927] credp: chroot: credential 0::27 not present in source SRC::9990006
[15546.575958] credp: chroot: credential 0::32 not present in source SRC::9990006
[15546.575988] credp: chroot: credential 0::33 not present in source SRC::9990006
[15546.576019] Aegis: credp_kcheck failed 9990006 bash
[15546.576049] Aegis: bash verification failed (source origin check)
[15553.154815] credp: chroot: credential 0::1 not present in source SRC::9990006
[15553.154876] credp: chroot: credential 0::6 not present in source SRC::9990006
[15553.154907] credp: chroot: credential 0::7 not present in source SRC::9990006
[15553.154937] credp: chroot: credential 0::16 not present in source SRC::9990006
[15553.154968] credp: chroot: credential 0::17 not present in source SRC::9990006
[15553.154998] credp: chroot: credential 0::21 not present in source SRC::9990006
[15553.155029] credp: chroot: credential 0::27 not present in source SRC::9990006
[15553.155059] credp: chroot: credential 0::32 not present in source SRC::9990006
[15553.155090] credp: chroot: credential 0::33 not present in source SRC::9990006
[15553.155120] Aegis: credp_kcheck failed 9990006 bash
[15553.155151] Aegis: bash verification failed (source origin check)
[15556.521179] credp: chroot: credential 0::1 not present in source SRC::9990006
[15556.521209] credp: chroot: credential 0::6 not present in source SRC::9990006
[15556.521240] credp: chroot: credential 0::7 not present in source SRC::9990006
[15556.521270] credp: chroot: credential 0::16 not present in source SRC::9990006
[15556.521331] credp: chroot: credential 0::17 not present in source SRC::9990006
[15556.521362] credp: chroot: credential 0::21 not present in source SRC::9990006
[15556.521392] credp: chroot: credential 0::27 not present in source SRC::9990006
[15556.521423] credp: chroot: credential 0::32 not present in source SRC::9990006
[15556.521453] credp: chroot: credential 0::33 not present in source SRC::9990006
[15556.521484] Aegis: credp_kcheck failed 9990006 bash
[15556.521514] Aegis: bash verification failed (source origin check)
[15558.726684] credp: chroot: credential 0::1 not present in source SRC::9990006
[15558.726745] credp: chroot: credential 0::6 not present in source SRC::9990006
[15558.726776] credp: chroot: credential 0::7 not present in source SRC::9990006
[15558.726806] credp: chroot: credential 0::16 not present in source SRC::9990006
[15558.726837] credp: chroot: credential 0::17 not present in source SRC::9990006
[15558.726867] credp: chroot: credential 0::21 not present in source SRC::9990006
[15558.726898] credp: chroot: credential 0::27 not present in source SRC::9990006
[15558.726928] credp: chroot: credential 0::32 not present in source SRC::9990006
[15558.726989] credp: chroot: credential 0::33 not present in source SRC::9990006
[15558.727020] Aegis: credp_kcheck failed 9990006 bash
[15558.727050] Aegis: bash verification failed (source origin check)
 
Posts: 1,067 | Thanked: 2,377 times | Joined on Jan 2012 @ Finland
#25
Originally Posted by qole View Post
Since the primary problem is that Aegis blocks the running of all unsigned binaries, and the chroot is all unsigned binaries, you would have to disable Aegis entirely. At which point, it is the same as Open Mode.
Well that is not true, you don't have to disable aegis entirely by echo 0.

Its enough just to echo 0x25 > /sys/kernel/security/validator/enabled

And then all unsigned binaries run just fine (and it also removes source origin check errors that above post has). Of course you first need to insmod kernel module which removes the seal bit so you can write to that file.
 

The Following User Says Thank You to rainisto For This Useful Post:
Posts: 23 | Thanked: 11 times | Joined on Nov 2011
#26
Originally Posted by rainisto View Post
Well that is not true, you don't have to disable aegis entirely by echo 0.

Its enough just to echo 0x25 > /sys/kernel/security/validator/enabled

And then all unsigned binaries run just fine (and it also removes source origin check errors that above post has). Of course you first need to insmod kernel module which removes the seal bit so you can write to that file.
/bin # echo 0x25 > /sys/kernel/security/validator/enabled
sh: write error: Operation not permitted

#manually write to /sys/kernel/security/validator/enabled
/bin # cat /sys/kernel/security/validator/enabled
0x1e7

still seeing
/bin # debian
sh: debian: Operation not permitted
 
Posts: 245 | Thanked: 908 times | Joined on Feb 2012
#27
Looks like this is a bit trickier than I'd hoped.

Globally disabling origin checking (as above) ought to do the trick, but if full root access isn't needed inside the chroot, it should suffice to:

a) install the chroot scripts from a package, requesting the needed credentials to set up the bind mounts etc.
b) relinquish those credentials when it comes time to actually start the chroot

Something such as /usr/bin/aegis-exec -c -a CAP::sys_chroot /bin/chroot /path/to/jail /sbin/capsh --caps='' -- -c '/path/to/payload' ought to work (this requires libcap2-bin inside the jail)

Also, @z720 - rainisto's suggestion only works if Aegis is "unsealed", which isn't the case on a fully booted system. It should be possible to change this, but that requires a kernel module that no one has put together yet for current kernel versions.
 
Posts: 1,067 | Thanked: 2,377 times | Joined on Jan 2012 @ Finland
#28
Originally Posted by z720 View Post
/bin # echo 0x25 > /sys/kernel/security/validator/enabled
sh: write error: Operation not permitted
You should read the whole post, I clearly said that you will get permission denied if you don't disable the seal bit which is protecting that file. If you don't know how to make (or where to get) such a kernel module, then your out of luck.

And yes I have a working module which does that in PR1.2, and no, I will not post it on this forum.
 
javispedro's Avatar
Posts: 2,330 | Thanked: 5,197 times | Joined on Jan 2009 @ Barcelona
#29
Originally Posted by qole View Post
Please verify that what you write is true; twoboxen reports that he is experiencing the same problems with Inception that I experienced with javispedro's earlier Aegis hack, that is, all binaries within the chroot receive a "Permission Denied" error unless Aegis is completely disabled.
This is because this is an Aegis crack and not open mode; like with the beta cracks, you will need to insmod unseal.ko .
And you will also need to still request permissions manually and so on for all packages.

Personally, I think this is the wrong approach to take (as explained in the original FMC aegis thread), exploring the real open mode is much more promising and future proof.
 

The Following User Says Thank You to javispedro For This Useful Post:
Posts: 1,067 | Thanked: 2,377 times | Joined on Jan 2012 @ Finland
#30
Originally Posted by javispedro View Post
This is because this is an Aegis crack and not open mode; like with the beta cracks, you will need to insmod unseal.ko .
And you will also need to still request permissions manually and so on for all packages.

Personally, I think this is the wrong approach to take (as explained in the original FMC aegis thread), exploring the real open mode is much more promising and future proof.
Well, if you boot to Open Mode with stock kernel, you still need to insmod module in order to make aegis less strict (I've written my module originally for open mode stock kernel). Its only when you boot to open mode with Aegis cracked kernel when things are easier.

Open mode is future proof, yes, most likely it will not get blocked. But Open Mode has a disadvantage in the fact that CAL nand area is always read-only. So unless you rewrite all the system modules that use CAL to not to use it (and as most of the services using cal are not open sourced) then you will never have 100% matching functionality to Closed Mode phone while being Open Mode. You can get near 99.5% by rewriting most common usecases, like reimplementing devicelock, but I have not seen any open mode developers doing that kind of rewrites.

Using exploits in Closed Mode is wrong approach too, since its quite likely that public exploits are going to be fixed if it poses thread of being misused by malware.

In optimal perfect world there would either be
A) com.nokia.maemo signed imei based develsh package that you would buy from ovi store or something, and which needs some manual/visual confirmation (so malware cannot install it without user noticing) before it is installed. That way nobody would need to use any exploits in order to get full access to their hardware and software.
B) Or the other way around if open mode would not trigger CAL to read-only.
C) Closed mode would not have SEAL_BIT enabled (if you enable R&D mode with flasher) and develsh privileges would be able to edit the file.
D) bootloader is changed to trust even unsigned kernels

But we do not live in perfect world... and most likely A, B, C or D will never happen. But you can always hope for the miracle.

Disclaimer: this is only my personal opinion, like all my posts. IMHO Aegis is a good thing and it protects file integrity quite well, and it should not be disabled even on open mode, but in some occasions policies might need do be a bit less strict if your a developer who is doing experimental stuff to their own device.
 

The Following 4 Users Say Thank You to rainisto For This Useful Post:
Reply

Tags
chroot, debian, harmattan

Thread Tools

 
Forum Jump


All times are GMT. The time now is 06:02.