Hi,
It seems there is/was a problem using NFS security labels where the server and client use
different MAC policy or model.
I was reading this page,
http://www.selinuxproject.org/page/Labeled_NFS/TODO#Label_Translation_Framework
It seems like this problem was known in 2009 when this page was written. Is
there a way to accomplish having extended attributes shared over NFS to a client
with different selinux policies ?
Maybe it's possible to allow the client to write local file context without
writing that down to the remote filesystem.
Thanks,
Daniel
On Thu, 2024-03-14 at 23:49 +0000, Daniel Walker (danielwa) wrote:
> Hi,
>
> It seems there is/was a problem using NFS security labels where the server and client use
> different MAC policy or model.
>
> I was reading this page,
>
> http://www.selinuxproject.org/page/Labeled_NFS/TODO#Label_Translation_Framework
>
> It seems like this problem was known in 2009 when this page was written. Is
> there a way to accomplish having extended attributes shared over NFS to a client
> with different selinux policies ?
>
Currently Linux NFS client and server only support limited server mode,
where the server presents the contexts as they are and the client
enforces its own policy locally. There's no requirement that the server
enforce the same policy (or even enforce a security policy at all), all
it's doing is storing and presenting the security label.
So what you're saying should "work" today.
> Maybe it's possible to allow the client to write local file context without
> writing that down to the remote filesystem.
>
That could be done. Just prevent the client from sending updates to the
security context to the server based on some switch.
But...what do you do when you make a local change and then the inode
gets cycled out of the cache? Once you bring it back in, it's going to
revert to its old setting. That sort of thing sounds like it would be of
limited utility.
--
Jeff Layton <[email protected]>
On Fri, Mar 15, 2024 at 11:47:27AM -0400, Jeff Layton wrote:
> On Thu, 2024-03-14 at 23:49 +0000, Daniel Walker (danielwa) wrote:
> > Hi,
> >
> > It seems there is/was a problem using NFS security labels where the server and client use
> > different MAC policy or model.
> >
> > I was reading this page,
> >
> > http://www.selinuxproject.org/page/Labeled_NFS/TODO#Label_Translation_Framework
> >
> > It seems like this problem was known in 2009 when this page was written. Is
> > there a way to accomplish having extended attributes shared over NFS to a client
> > with different selinux policies ?
> >
>
> Currently Linux NFS client and server only support limited server mode,
> where the server presents the contexts as they are and the client
> enforces its own policy locally. There's no requirement that the server
> enforce the same policy (or even enforce a security policy at all), all
> it's doing is storing and presenting the security label.
>
> So what you're saying should "work" today.
>
My situation is more constrained than this. The server would also have an selinux
policy which is active and in use. Server selinux usage is out the users
control.
This could plausibly come up where you have an nfsroot or nfs pivot root
environment with selinux is active and the server also has a different or
conflicting selinux policy active.
I was looking for a way to translate between the two selinux policies which is
how I found the link I provided.
Daniel