Tai Nguyen (tainguye) wrote:
All,
I understand that the build process compiles all sepolicy text files
into a binary file, however, I wonder if it is possible to update/add
new policy at runtime? That is, if we ship a product with a loose
security policy and let customers add on new policies based on their
security needs.
Not currently. As of right now you can
1) apps that are separate by using categories
2) encapsulate policy you want to change in booleans and use booleans to
'loosen' or 'tighten' the system.
3) update the policy via DeviceAdmin (you'll need an MDM solution that
uses those functions)
#1 and #2 are currently in the policy and do not require external support.
Secondly, I ran audit2allow tools and get the attached rules. Since I'm
new to these rules, and going along with the loose assumption above, I
wonder if these rules create any serious security hole given that we
don't have root access on the device.
raw denials are typically more helpful since they give more context.
Most of the shell ones are from running ps, those should probably get
dontaudited (the default policy, at least as of now, has a fairly
limited adb shell).
the unlabeled stuff could be from not wiping /data, from an old pre-asec
labeling system or something on your system isn't labeled and that
should never be allowed. The denials would help.
not sure what the system ones are
the untrusted_app ones also look like accesses to /proc but they aren't
all listed so I don't think it was running ps
Thanks,
Tai
--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe seandroid-list" without quotes as the message.
