Strange Associate bug

Strange Associate bug

[Daniel J Walsh]

If I mount an NFS filesystem and then try to move a file to it,
I get permission denied and end up with an associate error

 >mount remote:/vol/vol1/home /mnt/dwalsh
 >touch /home/dwalsh/foo
 >mv /home/dwalsh/foo /mnt/dwalsh
mv: cannot create regular file `./foo': Permission denied
Sep 17 15:48:19 celtics kernel: audit(1095450499.359:0): avc:  denied  { 
associate } for  pid=19797 exe=/bin/mv name=foo 
scontext=user_u:object_r:user_home_t tcontext=system_u:object_r:nfs_t 
tclass=filesystem

allow user_home_t nfs_t:filesystem { associate };

Do I need to change mv to be able to handle this or do we need

allow domain nfs_t:filesystem associate;

Dan

--
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: Strange Associate bug

[Stephen Smalley]

On Fri, 2004-09-17 at 15:52, Daniel J Walsh wrote:
> If I mount an NFS filesystem and then try to move a file to it,
> I get permission denied and end up with an associate error
> 
>  >mount remote:/vol/vol1/home /mnt/dwalsh
>  >touch /home/dwalsh/foo
>  >mv /home/dwalsh/foo /mnt/dwalsh
> mv: cannot create regular file `./foo': Permission denied
> Sep 17 15:48:19 celtics kernel: audit(1095450499.359:0): avc:  denied  { 
> associate } for  pid=19797 exe=/bin/mv name=foo 
> scontext=user_u:object_r:user_home_t tcontext=system_u:object_r:nfs_t 
> tclass=filesystem
> 
> allow user_home_t nfs_t:filesystem { associate };
> 
> Do I need to change mv to be able to handle this or do we need
> 
> allow domain nfs_t:filesystem associate;

You mean:
allow file_type nfs_t:filesystem associate;

Options are:
1) Change the kernel code to ignore the fscreate context when the
filesystem uses genfs_contexts, similar to the existing mount context=
handling, or
2) Change mv to reset the fscreate context to NULL and retry if the file
creation fails with EACCES, thereby falling back to the default labeling
behavior,
3) Allow the association, as above.

Allowing the association is a bit misleading, because the file is going
to revert to the base type ultimately, even if the incore inode happens
to be temporarily labeled with the fscreate context.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: Strange Associate bug

[Colin Walters]

On Fri, 2004-09-17 at 16:06 -0400, Stephen Smalley wrote:

> Options are:
> 1) Change the kernel code to ignore the fscreate context when the
> filesystem uses genfs_contexts, similar to the existing mount context=
> handling, or
> 2) Change mv to reset the fscreate context to NULL and retry if the file
> creation fails with EACCES, thereby falling back to the default labeling
> behavior,

What about:

2a) Change the kernel to return EOPNOTSUPP if fscreate context is non-
NULL for a genfs filesystem, and change mv to retry with NULL if the
operation fails with EOPNOTSUPP, but also print a warning.

> 3) Allow the association, as above.
> 
> Allowing the association is a bit misleading, because the file is going
> to revert to the base type ultimately, even if the incore inode happens
> to be temporarily labeled with the fscreate context.

Yeah, that sounds bad.



--
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.