On 10/11/2013 03:10 PM, Tai Nguyen (tainguye) wrote:
> My process creates a dir /tmp/isys then mount a file system on that
> directory. /tmp has tmpfs label.
>
> I see these audit message on mount and unmount.
>
> audit.old:audit(1381509622.789:19): avc: denied { mount } for pid=2811
> comm="ctapSteps124518" name="/" dev=mmcblk0p13 ino=65
> scontext=u:r:cisco_super:s0 tcontext=u:object_r:labeledfs:s0 tclass=filesystem
> audit.old:audit(1381509622.804:20): avc: denied { unmount } for pid=2811
> comm="ctapSteps124518" scontext=u:r:cisco_super:s0
> tcontext=u:object_r:labeledfs:s0 tclass=filesystem
>
> The block filesystem mmcblk0p13 is a labeled squashfs file system. Is that
> the reason it has label labeledfs?
>
> My process also mount different (unlabeled) filesystem and there is no audit
> message in those cases. So, I'm not sure why it doesn't have permission to
> mount mmcblk0p13. Is labeledfs filesystem treated differently than unlabeled
> one?
There should be a permission check regardless, but the type will be
different. I assume you allowed that domain to mount
unlabeled:filesystem or whatever type its filesystem type is assigned
(e.g. could be sdcard_external if vfat). Check your policy. Default
policy allows sdcardd and vold to mount sdcard_type and it allows vold
to mount labeledfs, and it allows zygote and vold to mount tmpfs. And
of course init is unconfined and thus can mount any fs type.
> Also, I wonder what is the normal way to test selinux policy. I was thinking
> that having some transition rules to transition shell to some test domain so
> that we can test the policy for that test domain. For example, if I want to
> test if the device has the right policy to domain d then I can transition
> from shell to d then test if d can access to files that it should not be able
> to, or do operation that it should not be able to. Does it make sense?
If you are testing app domains, then you could just assign the domain to
your app via seap_contexts and run your tests from it.
If you are trying to test some other process domain, e.g. a daemon
domain, then yes, you could take the approach you describe.
selinux-testsuite defines a suite of test domains and transitions to
them to exercise many of the kernel permission checks, but that is
oriented to regression testing the kernel, not a particular policy, and
presently only runs on Linux distributions, not on Android.
You can also use neverallow rules in your policy to ensure that you
never unintentionally allow certain permissions in it, as checkpolicy
will check those at policy build time and fail if one is violated.
Those used to live in external/sepolicy/assert.te in our policy but have
been split up among the various .te files in the current policy.
--
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.
