Oh, and yes, your assumptions are indeed correct. It is a su binary launched as a daemon.
And I'm glad to hear that SEAndroid can distinguish different types of netlink sockets. So, I could allow NETLINK_NFLOG sockets with sepolicy-inject, if it does becomes necessary to do so. On Fri, Apr 25, 2014 at 9:05 AM, pragma <[email protected]> wrote: > Thanks again for the excellent response. > > I received a report of the failure from a user out in the field, and I > have actually not yet reproduced it personally since I've refrained > from upgrading Android on my device because I am a heavy user > of root apps and am leery of SEAndroid breaking my tools. But > I suppose it's time to bite that bullet and learn how to work with > SEAndroid policies. > > I am somewhat concerned about the ramifications of using > sepolicy-inject on an end-user's device. I could display a dialog > explaining that I intend to update their SEAndroid policy to allow > executing a binary from the /data folder and only continue if they > explicitly confirm the action. I will have to learn how to do this > so that only the nflog binary belonging to the app is allowed > rather than allowing all binaries in /data to be executed. As > I said, it's time for me to get with the times and learn about > SEAndroid! > > > On Fri, Apr 25, 2014 at 6:00 AM, Stephen Smalley <[email protected]>wrote: > >> 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].
