On 04/24/2014 05:20 PM, pragma wrote: > Thanks for the response. > > They aren't setuid binaries. The app invokes an interactive root shell > by executing su and then piping shell commands to it and reading > from it.
I assume you are referring to the form of su that runs as a daemon (launched via a custom install-recovery.sh) and receives commands over a socket? In that case, the su daemon runs in init's domain since there is no domain transition defined for install-recovery.sh, and any shell it spawns runs in the init_shell domain. Both of those domains are unconfined domains and therefore are completely unrestricted in current Android releases, although certain restrictions have been imposed even on unconfined domains in AOSP master. > I read your paper, "Security Enhanced (SE) Android: Bringing > Flexible MAC to Android", and there is this statement in it: > > "Next, the policy denied GingerBreak’s attempt to create > the netlink socket, as there is no legitimate need for user > shells or apps to create this type of socket." > > I do think that using netlink sockets to be able to read NFLOG > entries is a legitimate need, especially since there is no such > system service for this and that there is unlikely to be one. If it requires root, then it isn't really supported for apps by Android regardless of SELinux; you already need a custom ROM / rooted device in order to use such commands from an app in that situation. Whereas if you can get a system service to provide such functionality, then you can enable your app to work on stock Android. In the Gingerbreak example, the specific netlink protocol was allowed for non-root processes by Linux, so only SELinux restricted it. Note that SELinux can distinguish among different netlink protocols (at least to the extent to which we have defined separate classes in the kernel and policy), so it can for example distinguish NETLINK_NFLOG from NETLINK_KOBJECT_UEVENT sockets. > But in any case, I'm not very familiar with SELinux/SEAndroid > commands, and I would like to know if there's a simple way > for the app or the end-user to allow the nflog binary to access > netlink sockets. > > I am hoping for something not so all-or-nothing as executing > 'setenforce 0' and less invasive then moving the binary to > /system and chowning/chmodding it to be a system command. > Ideally, it'd be great if it were possible for the user to set an > exemption or to change the context -- is this or something similar > possible? If you are relying on the su daemon approach, then I wouldn't expect it to fail under current policies, as the init and init_shell domains are unconfined domains and would in fact be allowed to create and use NETLINK_NFLOG sockets. If it is failing for you on current Android, can you show the actual avc: denied messages from dmesg? That said, I can see that this will likely break under the AOSP master policy because there we have taken away the ability of unconfined domains to execute files from /data. That's a security enhancement to prevent running unauthorized code with privilege. For that, you will need to copy your binary to /system or change the policy. On a rooted device, you certainly have the power to change the policy, but that requires you to clone the AOSP tree, modify the policy sources, and rebuild a new policy. Or you could use a tool like sepolicy-inject [1] to modify the existing binary policy file and then reload that. [1] https://bitbucket.org/joshua_brindle/sepolicy-inject _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
