From: jonghwa3.lee@samsung.com
To: Lukasz Pawelczyk <l.pawelczyk@samsung.com>,
Casey Schaufler <casey@schaufler-ca.com>,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org
Cc: james.l.morris@oracle.com, serge@hallyn.com,
sangbae90.lee@samsung.com, inki.dae@samsung.com
Subject: Re: [PATCH] security: smack: Add support automatic Smack labeling
Date: Tue, 01 Sep 2015 17:01:46 +0900 [thread overview]
Message-ID: <55E55B6A.1020903@samsung.com> (raw)
In-Reply-To: <1441029540.2335.2.camel@samsung.com>
On 2015년 08월 31일 22:59, Lukasz Pawelczyk wrote:
> On pon, 2015-08-31 at 15:13 +0900, jonghwa3.lee@samsung.com 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.
Do you think that is just userspace's affair and couldn't be solved with
kernel's help?
I gently ask your comments.
Thanks,
Jonghwa
next prev parent reply other threads:[~2015-09-01 8:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-27 1:58 [PATCH] [RFC] security: smack: Add support automatic Smack labeling Jonghwa Lee
2015-08-27 1:58 ` [PATCH] " Jonghwa Lee
2015-08-28 17:32 ` Casey Schaufler
2015-08-31 6:13 ` jonghwa3.lee
2015-08-31 13:59 ` Lukasz Pawelczyk
2015-09-01 8:01 ` jonghwa3.lee [this message]
2015-09-02 5:32 ` Casey Schaufler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55E55B6A.1020903@samsung.com \
--to=jonghwa3.lee@samsung.com \
--cc=casey@schaufler-ca.com \
--cc=inki.dae@samsung.com \
--cc=james.l.morris@oracle.com \
--cc=l.pawelczyk@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sangbae90.lee@samsung.com \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.