From: Steve Dickson <SteveD@redhat.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>,
"J. Bruce Fields" <bfields@redhat.com>,
"David P. Quigley" <dpquigl@tycho.nsa.gov>,
Linux NFS list <linux-nfs@vger.kernel.org>,
Linux Security List <linux-security-module@vger.kernel.org>,
SELinux List <selinux@tycho.nsa.gov>
Subject: Re: [PATCH 13/14] NFSD: Server implementation of MAC Labeling
Date: Sat, 30 Mar 2013 18:49:19 -0400 [thread overview]
Message-ID: <51576BEF.50001@RedHat.com> (raw)
In-Reply-To: <20130330220759.GB12025@fieldses.org>
On 30/03/13 18:08, J. Bruce Fields wrote:
> On Sat, Mar 30, 2013 at 05:50:21PM -0400, Steve Dickson wrote:
>>
>>
>> On 28/03/13 14:58, J. Bruce Fields wrote:
>>> On Thu, Mar 28, 2013 at 09:54:04AM -0400, Steve Dickson wrote:
>>>> From: David Quigley <dpquigl@davequigley.com>
>>>>
>>>> This patch adds the ability to encode and decode file labels on the server for
>>>> the purpose of sending them to the client and also to process label change
>>>> requests from the client.
>>>>
>>>> Signed-off-by: Matthew N. Dodd <Matthew.Dodd@sparta.com>
>>>> Signed-off-by: Miguel Rodel Felipe <Rodel_FM@dsi.a-star.edu.sg>
>>>> Signed-off-by: Phua Eu Gene <PHUA_Eu_Gene@dsi.a-star.edu.sg>
>>>> Signed-off-by: Khin Mi Mi Aung <Mi_Mi_AUNG@dsi.a-star.edu.sg>
>>>> ---
>>>> fs/nfsd/nfs4proc.c | 41 +++++++++++++++++++
>>>> fs/nfsd/nfs4xdr.c | 116 ++++++++++++++++++++++++++++++++++++++++++++++++++---
>>>> fs/nfsd/nfsd.h | 6 ++-
>>>> fs/nfsd/vfs.c | 29 ++++++++++++++
>>>> fs/nfsd/vfs.h | 2 +
>>>> fs/nfsd/xdr4.h | 3 ++
>>>> 6 files changed, 191 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
>>>> index ae73175..bb17589 100644
>>>> --- a/fs/nfsd/nfs4proc.c
>>>> +++ b/fs/nfsd/nfs4proc.c
>>>> @@ -42,6 +42,36 @@
>>>> #include "current_stateid.h"
>>>> #include "netns.h"
>>>>
>>>> +#ifdef CONFIG_NFSD_V4_SECURITY_LABEL
>>>> +#include <linux/security.h>
>>>> +
>>>> +static inline void
>>>> +nfsd4_security_inode_setsecctx(struct svc_fh *resfh, struct nfs4_label *label, u32 *bmval)
>>>> +{
>>>> + struct inode *inode = resfh->fh_dentry->d_inode;
>>>> + int status;
>>>> +
>>>> + mutex_lock(&inode->i_mutex);
>>>> + status = security_inode_setsecctx(resfh->fh_dentry,
>>>> + label->label, label->len);
>>>> + mutex_unlock(&inode->i_mutex);
>>>> +
>>>> + if (status)
>>>> + /*
>>>> + * We should probably fail the whole open at this point,
>>>> + * but we've already created or opened the file, so it's
>>>> + * too late; So this seems the least of evils:
>>>> + */
>>>> + bmval[2] &= ~FATTR4_WORD2_SECURITY_LABEL;
>>>> +
>>>> + return;
>>>> +}
>>>> +#else
>>>> +static inline void
>>>> +nfsd4_security_inode_setsecctx(struct svc_fh *resfh, struct nfs4_label *label, u32 *bmval)
>>>> +{ }
>>>> +#endif
>>>> +
>>>> #define NFSDDBG_FACILITY NFSDDBG_PROC
>>>>
>>>> static u32 nfsd_attrmask[] = {
>>>> @@ -230,6 +260,9 @@ do_open_lookup(struct svc_rqst *rqstp, struct svc_fh *current_fh, struct nfsd4_o
>>>> (u32 *)open->op_verf.data,
>>>> &open->op_truncate, &open->op_created);
>>>>
>>>> + if (!status && open->op_label != NULL)
>>>> + nfsd4_security_inode_setsecctx(resfh, open->op_label, open->op_bmval);
>>>> +
>>>> /*
>>>> * Following rfc 3530 14.2.16, use the returned bitmask
>>>> * to indicate which attributes we used to store the
>>>> @@ -599,6 +632,9 @@ nfsd4_create(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
>>>> if (status)
>>>> goto out;
>>>>
>>>> + if (create->cr_label != NULL)
>>>> + nfsd4_security_inode_setsecctx(&resfh, create->cr_label, create->cr_bmval);
>>>> +
>>>> if (create->cr_acl != NULL)
>>>> do_set_nfs4_acl(rqstp, &resfh, create->cr_acl,
>>>> create->cr_bmval);
>>>> @@ -888,6 +924,11 @@ nfsd4_setattr(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
>>>> setattr->sa_acl);
>>>> if (status)
>>>> goto out;
>>>> + if (setattr->sa_label != NULL)
>>>> + status = nfsd4_set_nfs4_label(rqstp, &cstate->current_fh,
>>>> + setattr->sa_label);
>>>> + if (status)
>>>> + goto out;
>>>> status = nfsd_setattr(rqstp, &cstate->current_fh, &setattr->sa_iattr,
>>>> 0, (time_t)0);
>>>> out:
>>>> diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
>>>> index 0116886..52e219c 100644
>>>> --- a/fs/nfsd/nfs4xdr.c
>>>> +++ b/fs/nfsd/nfs4xdr.c
>>>> @@ -55,6 +55,11 @@
>>>> #include "cache.h"
>>>> #include "netns.h"
>>>>
>>>> +#ifdef CONFIG_NFSD_V4_SECURITY_LABEL
>>>> +#include <linux/security.h>
>>>> +#endif
>>>> +
>>>> +
>>>> #define NFSDDBG_FACILITY NFSDDBG_XDR
>>>>
>>>> /*
>>>> @@ -79,6 +84,24 @@ check_filename(char *str, int len)
>>>> return nfserr_badname;
>>>> return 0;
>>>> }
>>>> +#ifdef CONFIG_NFSD_V4_SECURITY_LABEL
>>>> +static struct nfs4_label *nfsd4_label_alloc(u32 len)
>>>> +{
>>>> + struct nfs4_label *label = NULL;
>>>> +
>>>> + if (len > NFS4_MAXLABELLEN)
>>>> + return ERR_PTR(-ENAMETOOLONG);
>>>
>>> This is returned as NFS4ERR_NAMETOOLONG.
>>>
>>> The 4.2 spec should note this case, if it's the right error. rfc 5661
>>> says that error's only for filenames, and doesn't allow it for setattr
>>> (which doesn't take a filename).
>> The 4.2 spec (draft-ietf-nfsv4-minorversion2-19.txt) defines two Labeled
>> NFS errors:
>> NFS4ERR_BADLABEL (Error Code 10093)
>> NFS4ERR_WRONG_LFS (Error Code 10092)
>>
>> and we currently don't define either one of them... So I guess that
>> will have to change...
>
> http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-19#section-11.1.3.1
> just says "The label specified is invalid in some manner" for
> NFS4ERR_BADLABEL.
>
> Anyway, that sounds like the right one for this case....
>
>> So what should NFS4ERR_BADLABEL map to in nfserrno()?
>
> I don't know; I guess I'd check out what errors can be returned from the
> code that sets a context.
Looking looking at the code under security/selinux, the popular returns
seem to be are
-EOPNOTSUPP, -EACCES, -EPERM and -EINVAL.
I say we go with -EINVAL....
steved.
next prev parent reply other threads:[~2013-03-30 22:49 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-28 13:53 [PATCH 00/14] nfs: 3.9-rc3 release (v2) Steve Dickson
2013-03-28 13:53 ` [PATCH 01/14] Security: Add hook to calculate context based on a negative dentry Steve Dickson
2013-03-28 13:53 ` [PATCH 02/14] Security: Add Hook to test if the particular xattr is part of a MAC model Steve Dickson
2013-03-29 11:43 ` Mimi Zohar
2013-03-29 18:40 ` J. Bruce Fields
2013-03-30 20:52 ` Steve Dickson
2013-03-28 13:53 ` [PATCH 03/14] LSM: Add flags field to security_sb_set_mnt_opts for in kernel mount data Steve Dickson
2013-03-28 13:53 ` [PATCH 04/14] SELinux: Add new labeling type native labels Steve Dickson
2013-03-28 13:53 ` [PATCH 05/14] NFSv4: Add label recommended attribute and NFSv4 flags Steve Dickson
2013-03-28 13:53 ` [PATCH 06/14] NFSv4: Introduce new label structure Steve Dickson
2013-03-28 15:37 ` J. Bruce Fields
2013-03-28 13:53 ` [PATCH 07/14] NFSv4: Extend fattr bitmaps to support all 3 words Steve Dickson
2013-03-28 13:53 ` [PATCH 08/14] NFS:Add labels to client function prototypes Steve Dickson
2013-03-28 13:54 ` [PATCH 09/14] NFS: Add label lifecycle management Steve Dickson
2013-03-28 13:54 ` [PATCH 10/14] NFS: Client implementation of Labeled-NFS Steve Dickson
2013-03-28 13:54 ` [PATCH 11/14] NFS: Extend NFS xattr handlers to accept the security namespace Steve Dickson
2013-03-28 13:54 ` [PATCH 12/14] Kconfig: Add Kconfig entry for Labeled NFS V4 client Steve Dickson
2013-03-28 13:54 ` [PATCH 13/14] NFSD: Server implementation of MAC Labeling Steve Dickson
2013-03-28 16:10 ` J. Bruce Fields
2013-03-28 16:14 ` J. Bruce Fields
2013-03-29 3:35 ` Dave Quigley
2013-03-29 14:40 ` J. Bruce Fields
2013-03-29 14:49 ` David Quigley
2013-03-29 15:18 ` Casey Schaufler
2013-03-29 18:42 ` J. Bruce Fields
2013-03-29 20:10 ` Casey Schaufler
2013-03-30 21:09 ` Steve Dickson
2013-04-01 12:54 ` Vu, Joseph
2013-04-01 15:55 ` David Quigley
2013-04-02 13:01 ` Vu, Joseph
2013-04-02 13:15 ` David Quigley
2013-04-01 16:53 ` Casey Schaufler
2013-03-31 2:47 ` Mimi Zohar
2013-03-30 23:13 ` Steve Dickson
2013-03-28 18:58 ` J. Bruce Fields
2013-03-28 19:19 ` J. Bruce Fields
2013-03-29 3:32 ` Dave Quigley
2013-03-29 14:23 ` J. Bruce Fields
2013-03-29 14:38 ` David Quigley
2013-03-30 21:50 ` Steve Dickson
2013-03-30 22:08 ` J. Bruce Fields
2013-03-30 22:49 ` Steve Dickson [this message]
2013-03-31 0:02 ` J. Bruce Fields
2013-03-31 0:23 ` Steve Dickson
2013-03-28 13:54 ` [PATCH 14/14] Kconfig: Add Kconfig entry for Labeled NFS V4 server Steve Dickson
-- strict thread matches above, loose matches on Subject: below --
2013-03-25 11:42 [PATCH 00/14] lnfs: 3.9-rc3 release Steve Dickson
2013-03-25 11:42 ` [PATCH 13/14] NFSD: Server implementation of MAC Labeling Steve Dickson
2013-02-18 18:47 [PATCH 00/14] lnfs: 3.8-rc7 release Steve Dickson
2013-02-18 18:47 ` [PATCH 13/14] NFSD: Server implementation of MAC Labeling Steve Dickson
2013-01-22 13:40 [PATCH 00/14] lNFS: 3.8-rc3 release Steve Dickson
2013-01-22 13:40 ` [PATCH 13/14] NFSD: Server implementation of MAC Labeling Steve Dickson
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=51576BEF.50001@RedHat.com \
--to=steved@redhat.com \
--cc=Trond.Myklebust@netapp.com \
--cc=bfields@fieldses.org \
--cc=bfields@redhat.com \
--cc=dpquigl@tycho.nsa.gov \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=selinux@tycho.nsa.gov \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).