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].
