On Wed, Nov 7, 2012 at 6:59 PM, Tai Nguyen (tainguye)
<taing...@cisco.com> wrote:
> Hi,
>
> Does seandroid use the same security policy model as selinux? Is there tools
> to help writing policies for seandroid?
SE Android at the kernel layer is SELinux, so the same documentation
and tooling for dealing with SELinux policy denials applies to SE
Android, modulo differences between the SE Android policy
configuration and the SELinux reference policy.
> We see lot of audit messages in our devices, so what is the best way for us
> to evaluate the current sepolicy with our customized image?
>
> Examples of audit messages on our devices
> [ 207.590637] type=1400 audit(1352325201.039:662): avc: denied {
> net_admin } for pid=1824 comm="iptables" capability=12
> scontext=u:r:shell:s0 tcontext=u:r:shell:s0 tclass=capability // not sure
> what process is 1824, ps output doesn't show it
Notice the comm="iptables" above. This means that the denial occurred
while executing the iptables command. Also note that the scontext was
u:r:shell:s0. So it happened either from an adb shell or from a shell
spawned by init, as we have domain transitions defined for both in
policy. Possibly we shouldn't be transitioning to shell from init if
you want to leave that unconfined. Or we could define multiple shell
domains depending on the caller.
> <5>[ 207.573608] type=1400 audit(1352325201.023:661): avc: denied {
> getopt } for pid=1824 comm="iptables" lport=255 scontext=u:r:shell:s0
> tcontext=u:r:shell:s0 tclass=rawip_socket
Same issue here; iptables running in the shell context.
> <5>[ 208.935302] type=1400 audit(1352325202.382:665): avc: denied { read
> } for pid=1840 comm="ps" name="cmdline" dev=proc ino=1258
> scontext=u:r:shell:s0 tcontext=u:r:init:s0 tclass=file
Trying to run ps from a shell; we don't allow unprivileged domains to
reach the /proc/pid entries of other domains by default. If do a 'su'
first, you shouldn't have a problem if this was just for development
purposes.
> <5>[ 209.023590] type=1400 audit(1352325202.468:669): avc: denied {
> getattr } for pid=1840 comm="ps" path="/proc/1422" dev=proc ino=5766
> scontext=u:r:shell:s0 tcontext=u:r:untrusted_app:s0:c52,c256 tclass=dir
Same as above.
>
> <5>[ 186.568542] type=1400 audit(1352325180.015:658): avc: denied { use }
> for pid=602 comm="WindowManagerPo" path="/dev/pvrsrvkm" dev=tmpfs ino=1643
> scontext=u:r:system:s0 tcontext=u:object_r:unlabeled:s0 tclass=fd // ps –Z
> doesn't show any unable process
Do you have the kernel patch to not apply permission checks to private
files in your kernel tree?
> <5>[ 181.409027] type=1400 audit(1352325174.859:656): avc: denied { write
> } for pid=1362 comm=534950537461636B205461736B laddr=10.122.69.35
> lport=36794 faddr=172.18.78.123 fport=5060 scontext=u:r:system_app:s0
> tcontext=u:r:system_app:s0 tclass=tcp_socket
Default policy doesn't allow network perms for system apps (apps
running in the system UID) as they don't typically need them. But you
could add net_domain(system_app) if this is truly required/desired.
But wondering whether the app truly needs system UID? As opposed to
just being a platform or release app?
> <5>[ 135.021667] type=1400 audit(1352325128.468:654): avc: denied {
> getattr } for pid=1806 comm="ps" path="/proc/1794" dev=proc ino=7723
> scontext=u:r:shell:s0 tcontext=u:r:init:s0 tclass=dir
> <5>[ 135.039611] type=1400 audit(1352325128.484:655): avc: denied {
> search } for pid=1806 comm="ps" name="1794" dev=proc ino=7723
> scontext=u:r:shell:s0 tcontext=u:r:init:s0 tclass=dir
>
More fallout from running ps from an unprivileged (non-su) shel.
--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to majord...@tycho.nsa.gov with
the words "unsubscribe seandroid-list" without quotes as the message.
