From: Lukasz Pawelczyk <l.pawelczyk@samsung.com>
To: jonghwa3.lee@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: Mon, 31 Aug 2015 15:59:00 +0200 [thread overview]
Message-ID: <1441029540.2335.2.camel@samsung.com> (raw)
In-Reply-To: <55E3F0A2.2070102@samsung.com>
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.
--
Lukasz Pawelczyk
Samsung R&D Institute Poland
Samsung Electronics
next prev parent reply other threads:[~2015-08-31 13:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-27 1:58 [PATCH] [RFC] " 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 [this message]
2015-09-01 8:01 ` jonghwa3.lee
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=1441029540.2335.2.camel@samsung.com \
--to=l.pawelczyk@samsung.com \
--cc=casey@schaufler-ca.com \
--cc=inki.dae@samsung.com \
--cc=james.l.morris@oracle.com \
--cc=jonghwa3.lee@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome