On Wed, Dec 30, 2015 at 11:53 AM, James Muir <[email protected]> wrote:
> On 15-12-29 05:22 PM, Stephen Smalley wrote:
>>>
>>> I don't understand why the filesystem relabelto operation is required (I
>>> suspect it may be related to our fs_use entry for ecryptfs). Even when
>>> the
>>> mount-point context matches the context of the vfat filesystem, you still
>>> need a relabelto operation (i.e. the operation still seems to be required
>>> even when we are relabeling from X to X).
>>
>>
>> Permission is always checked on a context= mount, regardless of
>> whether the context actually differs.
>
>
> Do you happen to know why selinux chooses to ignore the security label in
> that operation? Was it done just to simplify the implementation?
> Performance does not seem to be valid concern here.
It isn't ignoring the security label; it just isn't making a special
case check to see if the old label is the same as the new label before
applying the permission checks for a context= mount. If you specify a
context= mount, it just performs a fixed sequence of permission
checks, irrespective of the particular labels (this is also true of
relabeling a file). Also, even if the filesystem/superblock label
itself doesn't change, the use of a context= mount has an effect on
the label of all of the inodes within it, so it would need to check
whether any inode is affected.
>
>>> If we change the neverallow rule to something like this:
>>>
>>> neverallow domain {fs_type -contextmount_type -sdcard_type}:filesystem
>>> relabelto;
>>>
>>> Then everything works great. Unfortunately, we cannot do that without
>>> violating CDD :-(
>>
>>
>> Correct, and making this change in AOSP would violate the intent of
>> the neverallow in the first place as it would then be possible to
>> remount /system as a sdcard type and then write to it.
>
>
> I understand the intent of the aosp change (to prevent remounts under
> /system that change security context), but the effect of the sepolicy change
> is too broad. Can't you block context-remounts under /system without
> blocking them everywhere else, too?
I don't see a good way to do that without introducing further
permission checks in the kernel. To be clear, we are talking about
unmounting /system and then mounting it under a different context in
order to write to it. At that point we have no real way of
distinguishing. We control who can mount on /system, but there is not
a specific permission check between the label of the mount point
directory and the context= mount label.
>> I think the only real options here are either to try to get a
>> waiver/exception to the CDD for this one case, or don't use ecryptfs
>> over vfat. In Android 6.0, with adoptable storage, wouldn't the
>> sdcard be formatted with ext4 and thus your existing fs_use entry
>> would work fine?
>
>
> We need to support Lollipop. Further, some Marshmallow devices allow access
> to external storage in a "portable" mode.
Seems like you need a waiver/exception then.
And maybe petition to get the neverallow dropped from AOSP for future
Android releases.
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
