Re: [PATCH] security: smack: Add support automatic Smack labeling

[Casey Schaufler]

On 9/1/2015 1:01 AM, jonghwa3.lee@xxxxxxxxxxx wrote:
> On 2015ë 08ì 31ì 22:59, Lukasz Pawelczyk wrote:
>> On pon, 2015-08-31 at 15:13 +0900, jonghwa3.lee@xxxxxxxxxxx wrote:
>>> A rule is defined for a process, 'process A',  in smack rule table.
>>>
>>> ...
>>> Process A    device::A    arwx-
>>> ...
>>>
>>> The object 'device::A' will be used to a device node that 'process A'
>>> will access.
>>> However when the target device node is created  it's labeled with
>>> default label
>>> which is inherited from any of filesystem, ancestor,  or creating
>>> process.
>>> Let's say the default object label for devtmpfs is '_' which allows
>>> only read and
>>> write access. So we need the specific labeling by the authorized
>>> process as like
>>> udevd for the devtmpfs.
>>>
>>> In normal, smack label and access control follow the sequences,
>>>
>>> 1. Kernel module driver loaded
>>> 2. New device node is created  (/dev/aaa ,  '_')
>>> 3. Udevd gets uevent and appies udev rule (/dev/aaa, 'device::A')
>>> 4. 'Process A' accesses the device node ('Process A' --->
>>> 'device::A', MAY_WRITE)
>>> 5. Access is permitted.
>>>
>>> However, when labeling isn't done in proper time, result will be
>>> different,
>>>
>>> 1. Kernel module driver loaded
>>> 2. New device node is created  (/dev/aaa ,  '_')
>>> 3. 'Process A' accesses the device node ('Process A' ---> '_',
>>> MAY_WRITE)
>>> 4. Access is prohibited
>>>
>>> Can this situation be handled in current Smack subsystem?
>>> If so, could you give me an idea how to handle it.
>> This doesn't seem to be a Smack problem. This isn't even a kernel
>> problem. It's userspace race. You should wait for a proper udev event
>> that notifies after all udev rules are applied.
>>
>> I think there are 2 udev events. One that notifies that a device has
>> been added. Second that notifies where all the rules for the device has
>> been applied. You need to use the second one.
>>
>>
>>
> Yes you're right, it's not a problem of neither Smack nor kernel. However it will
> help to resolve the problem if there is a proper way to label handled by kernel
> at least for files created by kernel.(e.g. device node)
>
> I'm not sure whether there is a uevent for completion of applying rule.
>  (I couldn't catch any of such uevent with udevadm.)
> However even there is, I think kernel side labeling has obvious advantages.
>
> The every new files need proper labeling before working under Smack.
> The files created by user application can be labeled by the same process at once.
> So it doesn't need to consider delayed labeling before access.
> However, the files created by kernel has to wait user space's control to be used.
> The timing of user space's labeling is not precised. It can be delayed indefinitely.
> Yes it's userspace race, but if kernel help it, It can prevent such issues.
>
> My proposal might be not quite fancy. (It could degrade system's performance
> severely as like Casey pointed out) But I'd like to ask whether this attempt is
> useless.

The problem is that you're fixing the problem in the wrong place.
I see that there is an issue, but there are several ways you could
address it in udev. You could change udev so that instead of creating
the device and changing it's Smack label you could create the device
with a "-not-yet" suffix, change it's Smack label, then rename it to
the proper name. There are other approaches as well.

> Do you think that is just userspace's affair and couldn't be solved with
> kernel's help?

It *can* be fixed with the kernel's help, but it shouldn't.

> I gently ask your comments. 
>
> Thanks,
> Jonghwa
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/