headers
Eric Paris | 8 Dec 2010 20:45
Picon
Favicon

[PATCH] fs/vfs/security: pass last path component to LSM on inode creation

SELinux would like to implement a new labeling behavior of newly created
inodes.  We currently label new inodes based on the parent and the creating
process.  This new behavior would also take into account the name of the
new object when deciding the new label.  This is not the (supposed) full path,
just the last component of the path.

This is very useful because creating /etc/shadow is different than creating
/etc/passwd but the kernel hooks are unable to differentiate these
operations.  We currently require that userspace realize it is doing some
difficult operation like that and than userspace jumps through SELinux hoops
to get things set up correctly.  This patch does not implement new
behavior, that is obviously contained in a seperate SELinux patch, but it
does pass the needed name down to the correct LSM hook.  If no such name
exists it is fine to pass NULL.

Signed-off-by: Eric Paris <eparis <at> redhat.com>
---

 fs/btrfs/inode.c               |   13 +++++++------
 fs/btrfs/xattr.c               |    6 ++++--
 fs/btrfs/xattr.h               |    3 ++-
 fs/ext2/ext2.h                 |    2 +-
 fs/ext2/ialloc.c               |    5 +++--
 fs/ext2/namei.c                |    8 ++++----
 fs/ext2/xattr.h                |    6 ++++--
 fs/ext2/xattr_security.c       |    5 +++--
 fs/ext3/ialloc.c               |    5 +++--
 fs/ext3/namei.c                |    8 ++++----
 fs/ext3/xattr.h                |    4 ++--
 fs/ext3/xattr_security.c       |    5 +++--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Paris | 9 Dec 2010 16:52
Picon
Favicon

Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation

On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote:
> >>>>> "Eric" == Eric Paris <eparis <at> redhat.com> writes:

> So what happens when I create a file /home/john/shadow, does selinux
> (or LSM in general) then run extra checks because the filename is
> 'shadow' in your model?  

It's entirely a question of labeling and one that was discussed on the
LSM list in some detail:

http://marc.info/?t=129141308200002&r=1&w=2

The basic synopsis is that when a new inode is created SELinux must
apply some label.  It makes the decision for what label to apply based
on 3 pieces of information.

The label of the parent inode.
The label of the process creating the new inode.
The 'class' of the inode, S_ISREG, S_ISDIR, S_ISLNK, etc

This patch adds a 4th piece of information, the name of the object being
created.  An obvious situation where this will be useful is devtmpfs
(although you'll find other examples in the above thread).  devtmpfs
when it creates char/block devices is unable to distinguish between kmem
and console and so they are created with a generic label.  hotplug/udev
is then called which does some pathname like matching and relabels them
to something more specific.  We've found that many people are able to
race against this particular updating and get spurious denials in /dev.
With this patch devtmpfs will be able to get the labels correct to begin
with.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Stoffel | 9 Dec 2010 16:05

Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation

>>>>> "Eric" == Eric Paris <eparis <at> redhat.com> writes:

Eric> SELinux would like to implement a new labeling behavior of newly
Eric> created inodes.  We currently label new inodes based on the
Eric> parent and the creating process.  This new behavior would also
Eric> take into account the name of the new object when deciding the
Eric> new label.  This is not the (supposed) full path, just the last
Eric> component of the path.

Eric> This is very useful because creating /etc/shadow is different
Eric> than creating /etc/passwd but the kernel hooks are unable to
Eric> differentiate these operations.  We currently require that
Eric> userspace realize it is doing some difficult operation like that
Eric> and than userspace jumps through SELinux hoops to get things set
Eric> up correctly.  This patch does not implement new behavior, that
Eric> is obviously contained in a seperate SELinux patch, but it does
Eric> pass the needed name down to the correct LSM hook.  If no such
Eric> name exists it is fine to pass NULL.

I've looked this patch over, and maybe I'm missing something, but how
does knowing the name of the file really tell you anything, esp when
you only get the filename, not the path?  What threat are you
addressing with this change?  

So what happens when I create a file /home/john/shadow, does selinux
(or LSM in general) then run extra checks because the filename is
'shadow' in your model?  

I *think* the overhead shouldn't be there if SELINUX is disabled, but
have you confirmed this?  How you run performance tests before/after
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Stoffel | 9 Dec 2010 18:48

Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation

>>>>> "Eric" == Eric Paris <eparis <at> redhat.com> writes:

Eric> On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote:
>> >>>>> "Eric" == Eric Paris <eparis <at> redhat.com> writes:

>> So what happens when I create a file /home/john/shadow, does selinux
>> (or LSM in general) then run extra checks because the filename is
>> 'shadow' in your model?  

Eric> It's entirely a question of labeling and one that was discussed on the
Eric> LSM list in some detail:

Eric> http://marc.info/?t=129141308200002&r=1&w=2

Thank you for pointing me at this discussion.  I'm working my way
through it, but so far I'm not seeing any consensus that this is
really the proper thing to do.  I personally feel this should be in
userspace if at all possible.

Eric> The basic synopsis is that when a new inode is created SELinux
Eric> must apply some label.  It makes the decision for what label to
Eric> apply based on 3 pieces of information.

Eric> The label of the parent inode.
Eric> The label of the process creating the new inode.
Eric> The 'class' of the inode, S_ISREG, S_ISDIR, S_ISLNK, etc

These seem to be ok, if you're using label based security.  But since
I freely admit I'm not an expert or even a user, I'm just trying to
understand and push back to make sure we do what's good.  And which
(Continue reading)

Permalink | Reply | 0 comments |
headers
Serge Hallyn | 9 Dec 2010 17:05
Favicon

Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation

Quoting John Stoffel (john <at> stoffel.org):
> >>>>> "Eric" == Eric Paris <eparis <at> redhat.com> writes:
> 
> Eric> SELinux would like to implement a new labeling behavior of newly
> Eric> created inodes.  We currently label new inodes based on the
> Eric> parent and the creating process.  This new behavior would also
> Eric> take into account the name of the new object when deciding the
> Eric> new label.  This is not the (supposed) full path, just the last
> Eric> component of the path.
> 
> Eric> This is very useful because creating /etc/shadow is different
> Eric> than creating /etc/passwd but the kernel hooks are unable to
> Eric> differentiate these operations.  We currently require that
> Eric> userspace realize it is doing some difficult operation like that
> Eric> and than userspace jumps through SELinux hoops to get things set
> Eric> up correctly.  This patch does not implement new behavior, that
> Eric> is obviously contained in a seperate SELinux patch, but it does
> Eric> pass the needed name down to the correct LSM hook.  If no such
> Eric> name exists it is fine to pass NULL.
> 
> I've looked this patch over, and maybe I'm missing something, but how
> does knowing the name of the file really tell you anything, esp when
> you only get the filename, not the path?  What threat are you
> addressing with this change?  

Like you, I keep thinking back to this patch and going back and forth.
But to answer your question:  in some cases, the name of the file
(plus the context of the directory in which it is created) can tell
you what assumptions userspace will make about it.  And userspace most
definately is a part of the TCB, i.e. /bin/passwd and /bin/login.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Paris | 9 Dec 2010 19:05
Picon
Favicon

Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation

On Thu, 2010-12-09 at 12:48 -0500, John Stoffel wrote:
> >>>>> "Eric" == Eric Paris <eparis <at> redhat.com> writes:
> 
> Eric> On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote:
> >> >>>>> "Eric" == Eric Paris <eparis <at> redhat.com> writes:
> 
> Eric> This patch adds a 4th piece of information, the name of the
> Eric> object being created.  An obvious situation where this will be
> Eric> useful is devtmpfs (although you'll find other examples in the
> Eric> above thread).  devtmpfs when it creates char/block devices is
> Eric> unable to distinguish between kmem and console and so they are
> Eric> created with a generic label.  hotplug/udev is then called which
> Eric> does some pathname like matching and relabels them to something
> Eric> more specific.  We've found that many people are able to race
> Eric> against this particular updating and get spurious denials in
> Eric> /dev.  With this patch devtmpfs will be able to get the labels
> Eric> correct to begin with.
> 
> So your Label based access controls are *also* based on pathnames?
> Right?

Access decisions are still based solely on the label.  This patch can
influence how new objects get their label, which makes the access
decisions indirectly path based.  You'll find a reasonable summary and
commentary on lwn in this weeks security section.

------------------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Eric Paris | 8 Dec 2010 20:45
Picon
Favicon

[PATCH] fs/vfs/security: pass last path component to LSM on inode creation

SELinux would like to implement a new labeling behavior of newly created
inodes.  We currently label new inodes based on the parent and the creating
process.  This new behavior would also take into account the name of the
new object when deciding the new label.  This is not the (supposed) full path,
just the last component of the path.

This is very useful because creating /etc/shadow is different than creating
/etc/passwd but the kernel hooks are unable to differentiate these
operations.  We currently require that userspace realize it is doing some
difficult operation like that and than userspace jumps through SELinux hoops
to get things set up correctly.  This patch does not implement new
behavior, that is obviously contained in a seperate SELinux patch, but it
does pass the needed name down to the correct LSM hook.  If no such name
exists it is fine to pass NULL.

Signed-off-by: Eric Paris <eparis <at> redhat.com>
---

 fs/btrfs/inode.c               |   13 +++++++------
 fs/btrfs/xattr.c               |    6 ++++--
 fs/btrfs/xattr.h               |    3 ++-
 fs/ext2/ext2.h                 |    2 +-
 fs/ext2/ialloc.c               |    5 +++--
 fs/ext2/namei.c                |    8 ++++----
 fs/ext2/xattr.h                |    6 ++++--
 fs/ext2/xattr_security.c       |    5 +++--
 fs/ext3/ialloc.c               |    5 +++--
 fs/ext3/namei.c                |    8 ++++----
 fs/ext3/xattr.h                |    4 ++--
 fs/ext3/xattr_security.c       |    5 +++--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane