On 04/30/2015 09:35 AM, William Roberts wrote: > > On Apr 30, 2015 6:24 AM, "Stephen Smalley" <[email protected] > <mailto:[email protected]>> wrote: >> >> On 04/30/2015 08:55 AM, Stephen Smalley wrote: >> > On 04/30/2015 05:41 AM, Inamdar Sharif wrote: >> >> Hi Guys, >> >> >> >> I just came across the change >> >> > https://android.googlesource.com/kernel/common/+/ba733f9857b966459316d0cd33b8da2e22f62d7d >> >> >> >> >> >> >> >> These are some of the questions: >> >> >> >> 1)What level of security this can provide?? Can anyone explain me with >> >> an example? >> > >> > See http://marc.info/?l=selinux&m=142861645215267&w=2 >> > >> >> 2)Also do we have any policy changes which would be required?? >> > >> > In order to use this mechanism, you need to update the target policy >> > version to 30 (either change the default POLICYVERS to 30 in >> > external/sepolicy/Android.mk or override it on the make command-line or >> > in your BoardConfig) and you need to write allow rules with ioctl >> > command whitelists. Otherwise, nothing changes by default. >> > >> >> Currently we have “ioctl” as the generic permission , so this means > that >> >> with this we have to specify which ioctl which source can >> >> access??(correct me if I am wrong) >> > >> > The ioctl whitelists are only applied if specified in policy; if no >> > whitelist is specified for a given (domain, type, class) triple, then it >> > only checks the existing ioctl generic permission. So you can apply the >> > ioctl whitelisting selectively. >> > >> >> Also doing this will not add to the policy ?? >> > >> > Not sure what you mean, but you have to add allow rules with ioctl >> > whitelists if you want to control them at that granularity. But you >> > still must be allowed ioctl permission in the first place, or no access >> > will be granted. So this mechanism can only further restrict ioctl >> > access to specific whitelists; it never allows something that would have >> > been denied. >> >> Also, note that there have been a couple of bug fixes to the original >> kernel patch so you'll want to cherry-pick those as well if using this >> mechanism. >> >> And you will need a version of libsepol and checkpolicy that supports >> policy version 30. Those changes have been applied on AOSP master and >> to the upstream selinux repository > > Is this on any versioned kernel yet or just master? Are they cherry > picking this back to older kernel versions since android is usually behind?
It is on android-3.4, android-3.10, android-3.14, and android-3.18 branches of kernel/common. It hasn't yet been merged upstream but I did ack it already. Just waiting a code review by Paul Moore there. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
