All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Quigley <dpquigl@davequigley.com>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>,
	Jeff Layton <jlayton@redhat.com>
Cc: "cye@redhat.com" <cye@redhat.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] nfs: fix oops when trying to set SELinux label
Date: Fri, 01 Nov 2013 22:46:10 -0400	[thread overview]
Message-ID: <52746772.4050803@davequigley.com> (raw)
In-Reply-To: <A1A30425-FA21-4D8B-ABB4-F7E02C2D5DEA@netapp.com>

On 11/1/2013 1:05 PM, Myklebust, Trond wrote:
>
> On Nov 1, 2013, at 12:57, Jeff Layton <jlayton@redhat.com> wrote:
>
>> On Fri, 1 Nov 2013 16:50:00 +0000
>> "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote:
>>
>>> On Fri, 2013-11-01 at 12:02 -0400, Jeff Layton wrote:
>>>> It looks like _nfs4_get_security_label() has the same problem, but I've
>>>> so far been unable to get it to be called, so I didn't patch it. It
>>>> seems like getxattr does some special stuff for SELinux labels that
>>>> cause them only to ever be fetched once.
>>>>
>>>> Is there some trick to it?
>>>>
>>>
>>> Doesn't 'ls -Z' cause them to security label to be read again?
>>>
>>
>> As best I can tell, security labels are set on the inode when the inode
>> is instantiated, and then are reset on changes (i.e. setxattr). If
>
> …and on getxattr, afaics.
>
>> another client changes the label though, it's not clear to me how your
>> client would ever notice it until the inode is dropped from the cache.
>>
>> ISTR Eric Paris explaining to me that they do that for performance
>> reasons but it seems like something that needs to be reconsidered in
>> light of labeled NFS. Not picking up a security label change seems like
>> a bug, IMO...
>
> To be effective, the security label should normally be set at file creation time. It should rarely, if ever, change. Why would you need to change it from a different client?
>
> Cheers,
>    Trond
>

That isn't completely true. Security labels should be set on creation 
but they may change. An SELinux label consists of 
user:role:type:level/categories. In RHEL and Fedora level/categories 
implements something called multi category security. One level multiple 
categories with the constraint on categories being that all must match 
for access to be allowed. This is how sVirt work. It picks two 
categories and setups the qemu process to start with these categories 
and then manipulates the files  on disk to have these categories such 
that even though the qemu_t proess can access the files type enforcement 
wise the categories deny it. Its what allows for SELinux based per 
process separation of a type.

Dave

  parent reply	other threads:[~2013-11-02  2:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-01 14:49 [PATCH] nfs: fix oops when trying to set SELinux label Jeff Layton
2013-11-01 16:02 ` Jeff Layton
2013-11-01 16:50   ` Myklebust, Trond
2013-11-01 16:57     ` Jeff Layton
2013-11-01 17:05       ` Myklebust, Trond
2013-11-01 17:18         ` Jeff Layton
2013-11-01 17:47           ` Myklebust, Trond
2013-11-01 17:58             ` Jeff Layton
2013-11-01 18:29               ` Myklebust, Trond
2013-11-02 11:05                 ` Jeff Layton
2013-11-02  2:46         ` Dave Quigley [this message]
2013-11-02  2:43       ` Dave Quigley
2013-11-02  2:41     ` Dave Quigley

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=52746772.4050803@davequigley.com \
    --to=dpquigl@davequigley.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=cye@redhat.com \
    --cc=jlayton@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    /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.