From: Jeff Layton <jlayton@kernel.org>
To: "Daniel Walker (danielwa)" <danielwa@cisco.com>,
"selinux@vger.kernel.org" <selinux@vger.kernel.org>
Cc: "xe-linux-external(mailer list)" <xe-linux-external@cisco.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: nfs client uses different MAC policy or model
Date: Fri, 15 Mar 2024 11:47:27 -0400 [thread overview]
Message-ID: <d4861b0541bac2670e39dc340f110bf72558b703.camel@kernel.org> (raw)
In-Reply-To: <ZfONIThp2RIfmu1O@goliath>
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 <jlayton@kernel.org>
next prev parent reply other threads:[~2024-03-15 15:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-14 23:49 nfs client uses different MAC policy or model Daniel Walker (danielwa)
2024-03-15 15:47 ` Jeff Layton [this message]
2024-03-15 23:09 ` Daniel Walker (danielwa)
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=d4861b0541bac2670e39dc340f110bf72558b703.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=danielwa@cisco.com \
--cc=linux-nfs@vger.kernel.org \
--cc=selinux@vger.kernel.org \
--cc=xe-linux-external@cisco.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.