filesystem mount AVC denial

filesystem mount AVC denial

[Clarkson, Mike R (US SSA)]

I got the following AVC denial in the audit logs and I'm wondering what
would cause this:

type=AVC msg=audit(1232734163.528:997720):avc: denied { mount } for
pid=28016 comm="find" name="/" dev=0:1c ino=0
scontext=root:staff_r:libstart_t:s0-s4:c0.c255
tcontext=system_u:object_r:nfs_t:s0 tclass=filesystem

The program running in the libstart_t domain is using the "find" cmd,
and find is requiring the "mount" permission. Could this be caused by
"find" traversing into an automounted (NFS) directory? But in that case
I would expect the automount daemon, which is running in the automount_t
domain, to do the mounting.

Thanks



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: filesystem mount AVC denial

[Stephen Smalley]

On Fri, 2009-01-30 at 15:45 -0800, Clarkson, Mike R (US SSA) wrote:
> I got the following AVC denial in the audit logs and I'm wondering what
> would cause this:
> 
> type=AVC msg=audit(1232734163.528:997720):avc: denied { mount } for
> pid=28016 comm="find" name="/" dev=0:1c ino=0
> scontext=root:staff_r:libstart_t:s0-s4:c0.c255
> tcontext=system_u:object_r:nfs_t:s0 tclass=filesystem
> 
> The program running in the libstart_t domain is using the "find" cmd,
> and find is requiring the "mount" permission. Could this be caused by
> "find" traversing into an automounted (NFS) directory? But in that case
> I would expect the automount daemon, which is running in the automount_t
> domain, to do the mounting.

Could be a nfs submount, triggered upon traversing the boundary?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: filesystem mount AVC denial

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Smalley wrote:
> On Fri, 2009-01-30 at 15:45 -0800, Clarkson, Mike R (US SSA) wrote:
>> I got the following AVC denial in the audit logs and I'm wondering what
>> would cause this:
>>
>> type=AVC msg=audit(1232734163.528:997720):avc: denied { mount } for
>> pid=28016 comm="find" name="/" dev=0:1c ino=0
>> scontext=root:staff_r:libstart_t:s0-s4:c0.c255
>> tcontext=system_u:object_r:nfs_t:s0 tclass=filesystem
>>
>> The program running in the libstart_t domain is using the "find" cmd,
>> and find is requiring the "mount" permission. Could this be caused by
>> "find" traversing into an automounted (NFS) directory? But in that case
>> I would expect the automount daemon, which is running in the automount_t
>> domain, to do the mounting.
> 
> Could be a nfs submount, triggered upon traversing the boundary?
> 
We had this happen on another bug report, and I think it is just wrong.

Since automounter could mount any file system or any file for that
matter, this means in order to make this work, any confined domain that
could traverse a directory that is automounted could fail with an AVC
like the above.

guest_t cd to /mynfs Would fail????

automount is doing the mount so the kernel should say automount not
libstart_t.

I think this is a bug in the kernel.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmHQzEACgkQrlYvE4MpobMO3ACfW9FgbwW8kyxyFTmuxP3tQDGn
UBkAn2UvIjC0A+vEo21ZpA/WhjVR8Y7R
=6luP
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: filesystem mount AVC denial

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Clarkson, Mike R (US SSA) wrote:
> I got the following AVC denial in the audit logs and I'm wondering what
> would cause this:
> 
> type=AVC msg=audit(1232734163.528:997720):avc: denied { mount } for
> pid=28016 comm="find" name="/" dev=0:1c ino=0
> scontext=root:staff_r:libstart_t:s0-s4:c0.c255
> tcontext=system_u:object_r:nfs_t:s0 tclass=filesystem
> 
> The program running in the libstart_t domain is using the "find" cmd,
> and find is requiring the "mount" permission. Could this be caused by
> "find" traversing into an automounted (NFS) directory? But in that case
> I would expect the automount daemon, which is running in the automount_t
> domain, to do the mounting.
> 
> Thanks
> 
> 
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.

What kernel?  Which policy?  Are you seeing this with.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmHRIYACgkQrlYvE4MpobMJ+gCeLBJFq5tpZfmNeRhdnnybTjfw
boEAoOsgE6KIrSJVK4T1oy1J4NGC2lX/
=xFOb
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: filesystem mount AVC denial

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Clarkson, Mike R (US SSA) wrote:
> I got the following AVC denial in the audit logs and I'm wondering what
> would cause this:
> 
> type=AVC msg=audit(1232734163.528:997720):avc: denied { mount } for
> pid=28016 comm="find" name="/" dev=0:1c ino=0
> scontext=root:staff_r:libstart_t:s0-s4:c0.c255
> tcontext=system_u:object_r:nfs_t:s0 tclass=filesystem
> 
> The program running in the libstart_t domain is using the "find" cmd,
> and find is requiring the "mount" permission. Could this be caused by
> "find" traversing into an automounted (NFS) directory? But in that case
> I would expect the automount daemon, which is running in the automount_t
> domain, to do the mounting.
> 
> Thanks
> 
> 
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.

The autofs maintainers have asked me to ask you to file a bug on autofs
and include the data requested on

http://people.redhat.com/jmoyer/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmHT7wACgkQrlYvE4MpobNqzACdHuAdi31QNzlp8bASxiQaLp0/
VtwAn0kAZG1Zm0kYSxqTJleKEubo/GpV
=BZQV
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: filesystem mount AVC denial

[Stephen Smalley]

On Mon, 2009-02-02 at 14:02 -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen Smalley wrote:
> > On Fri, 2009-01-30 at 15:45 -0800, Clarkson, Mike R (US SSA) wrote:
> >> I got the following AVC denial in the audit logs and I'm wondering what
> >> would cause this:
> >>
> >> type=AVC msg=audit(1232734163.528:997720):avc: denied { mount } for
> >> pid=28016 comm="find" name="/" dev=0:1c ino=0
> >> scontext=root:staff_r:libstart_t:s0-s4:c0.c255
> >> tcontext=system_u:object_r:nfs_t:s0 tclass=filesystem
> >>
> >> The program running in the libstart_t domain is using the "find" cmd,
> >> and find is requiring the "mount" permission. Could this be caused by
> >> "find" traversing into an automounted (NFS) directory? But in that case
> >> I would expect the automount daemon, which is running in the automount_t
> >> domain, to do the mounting.
> > 
> > Could be a nfs submount, triggered upon traversing the boundary?
> > 
> We had this happen on another bug report, and I think it is just wrong.
> 
> Since automounter could mount any file system or any file for that
> matter, this means in order to make this work, any confined domain that
> could traverse a directory that is automounted could fail with an AVC
> like the above.
> 
> guest_t cd to /mynfs Would fail????
> 
> automount is doing the mount so the kernel should say automount not
> libstart_t.
> 
> I think this is a bug in the kernel.

Yes, it is similar to the recent proc/self/net problem.

Eric?  James?  The fundamental issue is that we are performing a
permission check in a core function that gets used internally by the
kernel for mounts, not just when userspace initiates a mount.  In the
proc case we could use MS_KERNMOUNT as a discriminator, but not in this
case, at least at present.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: filesystem mount AVC denial

[Clarkson, Mike R (US SSA)]

> -----Original Message-----
> From: Daniel J Walsh [mailto:dwalsh@redhat.com]
> Sent: Monday, February 02, 2009 11:56 AM
> To: Clarkson, Mike R (US SSA)
> Cc: selinux@tycho.nsa.gov
> Subject: Re: filesystem mount AVC denial
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Clarkson, Mike R (US SSA) wrote:
> > I got the following AVC denial in the audit logs and I'm wondering
what
> > would cause this:
> >
> > type=AVC msg=audit(1232734163.528:997720):avc: denied { mount } for
> > pid=28016 comm="find" name="/" dev=0:1c ino=0
> > scontext=root:staff_r:libstart_t:s0-s4:c0.c255
> > tcontext=system_u:object_r:nfs_t:s0 tclass=filesystem
> >
> > The program running in the libstart_t domain is using the "find"
cmd,
> > and find is requiring the "mount" permission. Could this be caused
by
> > "find" traversing into an automounted (NFS) directory? But in that
case
> > I would expect the automount daemon, which is running in the
automount_t
> > domain, to do the mounting.
> >
> > Thanks
> >
> >
> >
> > --
> > This message was distributed to subscribers of the selinux mailing
list.
> > If you no longer wish to subscribe, send mail to
majordomo@tycho.nsa.gov
> with
> > the words "unsubscribe selinux" without quotes as the message.
> 
> The autofs maintainers have asked me to ask you to file a bug on
autofs
> and include the data requested on

OK. Will do

> 
> http://people.redhat.com/jmoyer/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkmHT7wACgkQrlYvE4MpobNqzACdHuAdi31QNzlp8bASxiQaLp0/
> VtwAn0kAZG1Zm0kYSxqTJleKEubo/GpV
> =BZQV
> -----END PGP SIGNATURE-----



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: filesystem mount AVC denial

[James Morris]

On Tue, 3 Feb 2009, Stephen Smalley wrote:

> > guest_t cd to /mynfs Would fail????
> > 
> > automount is doing the mount so the kernel should say automount not
> > libstart_t.
> > 
> > I think this is a bug in the kernel.

Well, the behavior I see with automount is:

avc:  granted  { mount } for  pid=3378 comm="mount" name="/" dev=sdc4 
ino=2 scontext=unconfined_u:system_r:mount_t:s0 
tcontext=system_u:object_r:fs_t:s0 tclass=filesystem

... always running as mount_t (in this case, I used runcon to 'ls' an 
automount from sshd_t).

> 
> Yes, it is similar to the recent proc/self/net problem.
> 
> Eric?  James?  The fundamental issue is that we are performing a
> permission check in a core function that gets used internally by the
> kernel for mounts, not just when userspace initiates a mount.  In the
> proc case we could use MS_KERNMOUNT as a discriminator, but not in this
> case, at least at present.

Firstly, why isn't Mike's example running as mount_t (and how do you 
define userspace initiating a mount -- does this include automounting?)

(Also, Dan asked for a bz to be filed with the autofs folk...)


-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: filesystem mount AVC denial

[Stephen Smalley]

On Wed, 2009-02-04 at 11:18 +1100, James Morris wrote:
> On Tue, 3 Feb 2009, Stephen Smalley wrote:
> 
> > > guest_t cd to /mynfs Would fail????
> > > 
> > > automount is doing the mount so the kernel should say automount not
> > > libstart_t.
> > > 
> > > I think this is a bug in the kernel.
> 
> Well, the behavior I see with automount is:
> 
> avc:  granted  { mount } for  pid=3378 comm="mount" name="/" dev=sdc4 
> ino=2 scontext=unconfined_u:system_r:mount_t:s0 
> tcontext=system_u:object_r:fs_t:s0 tclass=filesystem
> 
> ... always running as mount_t (in this case, I used runcon to 'ls' an 
> automount from sshd_t).
> 
> > 
> > Yes, it is similar to the recent proc/self/net problem.
> > 
> > Eric?  James?  The fundamental issue is that we are performing a
> > permission check in a core function that gets used internally by the
> > kernel for mounts, not just when userspace initiates a mount.  In the
> > proc case we could use MS_KERNMOUNT as a discriminator, but not in this
> > case, at least at present.
> 
> Firstly, why isn't Mike's example running as mount_t (and how do you 
> define userspace initiating a mount -- does this include automounting?)
> 
> (Also, Dan asked for a bz to be filed with the autofs folk...)

I was thinking that this was a manifestation of i_op->follow_link ->
nfs_follow_mountpoint() -> nfs_do_submount() -> nfs_do_clone_mount() ->
vfs_kern_mount() -> security_sb_kern_mount() -> selinux_sb_kern_mount().

Similar to the proc issue, we have a kernel-internal mount generated
upon accessing a symlink that shouldn't be subjected to a permission
check based on the current process.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.