On 4/1/2013 5:54 AM, Vu, Joseph wrote: > I think 2k will do for a while. I think that in the long run it will come up short. I think the real question is whether NFS will remain viable long enough for it to matter. > > What is a good, and working alternative for NFS in term of SE label? Answering this simple question is complicated. For the short term, I don't think there is one. For the long term I think that there has to be a resource oriented shared storage mechanism that will be very different from anything we have today. We are on the cusp of the transition from the short term to the long term. NFS, CIFS and the like are old school solutions to file sharing, just as mode bits and SELinux are old school security paradigms. I am on record as not favoring this implementation of security labeling in NFS. I believe that I understand the rationale for the approach, and as I don't have an alternative that hasn't been shot down three ways from Sunday I hope to make the best of it. > > > -----Original Message----- > From: owner-selinux@xxxxxxxxxxxxx [mailto:owner-selinux@xxxxxxxxxxxxx] On Behalf Of Casey Schaufler > Sent: Friday, March 29, 2013 3:10 PM > To: J. Bruce Fields > Cc: David Quigley; Steve Dickson; Trond Myklebust; J. Bruce Fields; David P. Quigley; Linux NFS list; Linux Security List; SELinux List; Casey Schaufler > Subject: Re: [PATCH 13/14] NFSD: Server implementation of MAC Labeling > > On 3/29/2013 11:42 AM, J. Bruce Fields wrote: >> On Fri, Mar 29, 2013 at 08:18:59AM -0700, Casey Schaufler wrote: >>> On 3/29/2013 7:49 AM, David Quigley wrote: >>>> On 03/29/2013 10:40, J. Bruce Fields wrote: >>>>> On Thu, Mar 28, 2013 at 11:35:31PM -0400, Dave Quigley wrote: >>>>>> On 3/28/2013 12:14 PM, J. Bruce Fields wrote: >>>>>>> On Thu, Mar 28, 2013 at 09:54:04AM -0400, Steve Dickson wrote: >>>>>>>> From: David Quigley <dpquigl@xxxxxxxxxxxxxxx> >>>>>>>> >>>>>>>> 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@xxxxxxxxxx> >>>>>>>> Signed-off-by: Miguel Rodel Felipe <Rodel_FM@xxxxxxxxxxxxxxxxx> >>>>>>>> Signed-off-by: Phua Eu Gene <PHUA_Eu_Gene@xxxxxxxxxxxxxxxxx> >>>>>>>> Signed-off-by: Khin Mi Mi Aung <Mi_Mi_AUNG@xxxxxxxxxxxxxxxxx> >>>>>>>> --- >>>>>>>> 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; >>>>>>> Is there any way to avoid this? >>>>>>> >>>>>>> How does the vfs open code handle this? It has to be able to set >>>>>>> a security contexts atomically on open(O_CREAT), doesn't it? >>>>>>> >>>>>> I believe the way this is handled is that the inode is created and >>>>>> labeled and then only after that is it bound to the namespace. >>>>>> Because of that ordering we can fail and release the inode without >>>>>> it ever having a dentry in the namespace. >>>>> Grepping around.... Looks like that's done by >>>>> security_inode_init_security(), from the filesystem's create method. >>>>> >>>>> So we'd need to be able to pass something down to there. >>>>> >>>>> Is the current client actually expected to use this? (So are we >>>>> going to see a lot of opens that set the label?) >>>>> >>>>> --b. >>>> I don't have all the code infront of me but we have a different hook >>>> to do that. The call to nfsd4_security_inode_setsecctx is supposed >>>> to be used from the setattr handlers to do the equivalent of a >>>> setxattr on the file over NFS. The actual creation gets done with >>>> something like security_dentry_init_security which should be in an >>>> earlier patch. I'd have to look more clearly at the code to find >>>> out. Also where did we come up with 128 for label length? The >>>> SELinux code assumes a starting point of 255 and goes up from there >>>> as needed. The MLS policies will definitely exceed a 128 byte label. >>> If anyone cares, Smack labels can (now) be 255 characters. >>> Also, when (if) we get multiple concurrent LSMs the "security >>> context" may include information for more than one LSM. 128 bytes is >>> going to look pretty tiny then. >>> >>> smack='com.corportation.service'selinux='system_u:object_r:bin_t:s0' >> OK. We need a number. 2k? > Consider some of the kinds of attributes we are likely to see in the not to distant future: > > Permitted access times, at around 100 bytes each. > Bell & LaPadula labels at 500 bytes each. > Signatures of various sizes and flavors. > HEPA restrictions > > I think 2k will do for a while. I think that in the long run it will come up short. I think the real question is whether NFS will remain viable long enough for it to matter. > >> --b. >> -- >> To unsubscribe from this list: send the line "unsubscribe >> linux-security-module" in the body of a message to >> majordomo@xxxxxxxxxxxxxxx More majordomo info at >> http://vger.kernel.org/majordomo-info.html >> > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message. > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
