From: "David P. Quigley" <dpquigl@tycho.nsa.gov> To: "J. Bruce Fields" <bfields@fieldses.org> Cc: hch@infradead.org, viro@zeniv.linux.org.uk, casey@schaufler-ca.com, sds@tycho.nsa.gov, matthew.dodd@sparta.com, trond.myklebust@fys.uio.no, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov, linux-nfs@vger.kernel.org Subject: Re: [PATCH 10/10] NFSD: Server implementation of MAC Labeling Date: Thu, 08 Jul 2010 09:27:37 -0400 [thread overview] Message-ID: <1278595657.2494.182.camel@moss-terrapins.epoch.ncsc.mil> (raw) In-Reply-To: <20100707192431.GK28815@fieldses.org> On Wed, 2010-07-07 at 15:24 -0400, J. Bruce Fields wrote: > On Wed, Jul 07, 2010 at 02:03:21PM -0400, David P. Quigley wrote: > > Comments inline > > > > On Wed, 2010-07-07 at 13:21 -0400, J. Bruce Fields wrote: > > > On Wed, Jul 07, 2010 at 10:31:26AM -0400, David P. Quigley wrote: > > > > This patch adds the ability to encode and decode file labels on the server for > > > > static __be32 > > > > nfsd4_decode_fattr(struct nfsd4_compoundargs *argp, u32 *bmval, > > > > - struct iattr *iattr, struct nfs4_acl **acl) > > > > + struct iattr *iattr, struct nfs4_acl **acl, > > > > + struct nfs4_label **label) > > > > > > As we add more arguments, I wonder if at some point it becomes worth > > > creating something like > > > > > > struct nfsd4_attrs { > > > struct iattr iattr; > > > struct nfs4_acl *acl; > > > ... > > > } > > > > > > and passing that instead? > > > > I can definitely submit something like that as a stand alone patch and > > then add our nfs4_label stuff to that instead. > > Not a big deal, but welcome if such a thing looks more generally useful > (say, if the same arguments are passed elsewhere). > > > > > +#ifdef CONFIG_NFSD_V4_SECURITY_LABEL > > > > + if (bmval[1] & FATTR4_WORD1_SECURITY_LABEL) { > > > > + uint32_t lfs; > > > > + > > > > + READ_BUF(4); > > > > + len += 4; > > > > + READ32(lfs); > > > > + READ_BUF(4); > > > > + len += 4; > > > > + READ32(dummy32); > > > > + READ_BUF(dummy32); > > > > + len += (XDR_QUADLEN(dummy32) << 2); > > > > + READMEM(buf, dummy32); > > > > + > > > > + if (dummy32 > NFS4_MAXLABELLEN) > > > > + return nfserr_resource; > > > > + > > > > + *label = kzalloc(sizeof(struct nfs4_label), GFP_KERNEL); > > > > > > Could we allocate this some toher way (it's small, right?) and avoid the > > > extra dynamic allocation here, just for simplicity's sake? > > > > How would you suggest going about doing that? > > Maybe make op_label, cr_label, etc., a struct nfs4_label instead of a > struct nfs4_label *? I'll look into this. Since the structure contains a void * for the label data it might not be necessary to have to allocate the label structure itself just make sure its zeroed out so we can check to see if its initialized with anything. > > > > > > > > > > + if (*label == NULL) { > > > > + host_err = -ENOMEM; > > > > + goto out_nfserr; > > > > + } > > > > + > > > > + (*label)->label = kmalloc(dummy32 + 1, GFP_KERNEL); > > > > > > Might be nice to arrange NFS4_MAXLABELLEN to ensure this is never a > > > higher-order allocation. > > > > This should never be more than 4096. Under what circumstances would this > > become a higher-order allocation? > > Can't dummy32+1 be 4097? You're right. My mistake. NFS4_MAXLABELLEN is supposed to include the null termination. I'll fix this. I wonder if its better to just redefine NFS4_MAXLABELLEN to be 4095 so when we use the extra null terminator it will be a page size max. > > --b.
WARNING: multiple messages have this Message-ID (diff)
From: "David P. Quigley" <dpquigl@tycho.nsa.gov> To: "J. Bruce Fields" <bfields@fieldses.org> Cc: hch@infradead.org, viro@zeniv.linux.org.uk, casey@schaufler-ca.com, sds@tycho.nsa.gov, matthew.dodd@sparta.com, trond.myklebust@fys.uio.no, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov, linux-nfs@vger.kernel.org Subject: Re: [PATCH 10/10] NFSD: Server implementation of MAC Labeling Date: Thu, 08 Jul 2010 09:27:37 -0400 [thread overview] Message-ID: <1278595657.2494.182.camel@moss-terrapins.epoch.ncsc.mil> (raw) In-Reply-To: <20100707192431.GK28815@fieldses.org> On Wed, 2010-07-07 at 15:24 -0400, J. Bruce Fields wrote: > On Wed, Jul 07, 2010 at 02:03:21PM -0400, David P. Quigley wrote: > > Comments inline > > > > On Wed, 2010-07-07 at 13:21 -0400, J. Bruce Fields wrote: > > > On Wed, Jul 07, 2010 at 10:31:26AM -0400, David P. Quigley wrote: > > > > This patch adds the ability to encode and decode file labels on the server for > > > > static __be32 > > > > nfsd4_decode_fattr(struct nfsd4_compoundargs *argp, u32 *bmval, > > > > - struct iattr *iattr, struct nfs4_acl **acl) > > > > + struct iattr *iattr, struct nfs4_acl **acl, > > > > + struct nfs4_label **label) > > > > > > As we add more arguments, I wonder if at some point it becomes worth > > > creating something like > > > > > > struct nfsd4_attrs { > > > struct iattr iattr; > > > struct nfs4_acl *acl; > > > ... > > > } > > > > > > and passing that instead? > > > > I can definitely submit something like that as a stand alone patch and > > then add our nfs4_label stuff to that instead. > > Not a big deal, but welcome if such a thing looks more generally useful > (say, if the same arguments are passed elsewhere). > > > > > +#ifdef CONFIG_NFSD_V4_SECURITY_LABEL > > > > + if (bmval[1] & FATTR4_WORD1_SECURITY_LABEL) { > > > > + uint32_t lfs; > > > > + > > > > + READ_BUF(4); > > > > + len += 4; > > > > + READ32(lfs); > > > > + READ_BUF(4); > > > > + len += 4; > > > > + READ32(dummy32); > > > > + READ_BUF(dummy32); > > > > + len += (XDR_QUADLEN(dummy32) << 2); > > > > + READMEM(buf, dummy32); > > > > + > > > > + if (dummy32 > NFS4_MAXLABELLEN) > > > > + return nfserr_resource; > > > > + > > > > + *label = kzalloc(sizeof(struct nfs4_label), GFP_KERNEL); > > > > > > Could we allocate this some toher way (it's small, right?) and avoid the > > > extra dynamic allocation here, just for simplicity's sake? > > > > How would you suggest going about doing that? > > Maybe make op_label, cr_label, etc., a struct nfs4_label instead of a > struct nfs4_label *? I'll look into this. Since the structure contains a void * for the label data it might not be necessary to have to allocate the label structure itself just make sure its zeroed out so we can check to see if its initialized with anything. > > > > > > > > > > + if (*label == NULL) { > > > > + host_err = -ENOMEM; > > > > + goto out_nfserr; > > > > + } > > > > + > > > > + (*label)->label = kmalloc(dummy32 + 1, GFP_KERNEL); > > > > > > Might be nice to arrange NFS4_MAXLABELLEN to ensure this is never a > > > higher-order allocation. > > > > This should never be more than 4096. Under what circumstances would this > > become a higher-order allocation? > > Can't dummy32+1 be 4097? You're right. My mistake. NFS4_MAXLABELLEN is supposed to include the null termination. I'll fix this. I wonder if its better to just redefine NFS4_MAXLABELLEN to be 4095 so when we use the extra null terminator it will be a page size max. > > --b. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.
next prev parent reply other threads:[~2010-07-08 13:35 UTC|newest] Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-07-07 14:31 Labeled-NFS: Security Label support in NFSv4 David P. Quigley 2010-07-07 14:31 ` David P. Quigley 2010-07-07 14:31 ` [PATCH 01/10] Security: Add hook to calculate context based on a negative dentry David P. Quigley 2010-07-07 14:31 ` David P. Quigley 2010-07-08 12:51 ` Stephen Smalley 2010-07-08 12:51 ` Stephen Smalley 2010-07-07 14:31 ` [PATCH 02/10] Security: Add Hook to test if the particular xattr is part of a MAC model David P. Quigley 2010-07-07 14:31 ` David P. Quigley 2010-07-07 16:49 ` J. Bruce Fields 2010-07-07 16:49 ` J. Bruce Fields 2010-07-07 14:31 ` [PATCH 03/10] LSM: Add flags field to security_sb_set_mnt_opts for in kernel mount data David P. Quigley 2010-07-07 14:31 ` David P. Quigley 2010-07-07 14:31 ` [PATCH 04/10] SELinux: Add new labeling type native labels David P. Quigley 2010-07-07 14:31 ` David P. Quigley 2010-07-07 23:23 ` James Morris 2010-07-07 23:23 ` James Morris 2010-07-08 13:31 ` David P. Quigley 2010-07-08 13:31 ` David P. Quigley 2010-07-08 22:33 ` James Morris 2010-07-08 22:33 ` James Morris 2010-07-09 14:09 ` David P. Quigley 2010-07-09 14:09 ` David P. Quigley 2010-07-07 14:31 ` [PATCH 05/10] KConfig: Add KConfig entries for Labeled NFS David P. Quigley 2010-07-07 14:31 ` David P. Quigley 2010-07-07 16:56 ` J. Bruce Fields 2010-07-07 16:56 ` J. Bruce Fields 2010-07-07 17:05 ` David P. Quigley 2010-07-07 17:05 ` David P. Quigley 2010-07-07 17:05 ` David P. Quigley 2010-07-07 17:53 ` Chuck Lever 2010-07-07 17:53 ` Chuck Lever 2010-07-07 14:31 ` [PATCH 06/10] NFSv4: Add label recommended attribute and NFSv4 flags David P. Quigley 2010-07-07 14:31 ` David P. Quigley 2010-07-07 17:00 ` J. Bruce Fields 2010-07-07 23:30 ` James Morris 2010-07-07 23:30 ` James Morris 2010-07-08 13:39 ` David P. Quigley 2010-07-08 13:39 ` David P. Quigley 2010-07-08 13:39 ` David P. Quigley 2010-07-08 13:39 ` David P. Quigley 2010-07-08 22:48 ` James Morris 2010-07-08 22:48 ` James Morris 2010-07-09 13:47 ` Stephen Smalley 2010-07-09 13:47 ` Stephen Smalley 2010-07-09 13:47 ` Stephen Smalley 2010-07-09 14:05 ` David P. Quigley 2010-07-09 14:05 ` David P. Quigley 2010-07-09 14:05 ` David P. Quigley 2010-07-11 5:02 ` Kyle Moffett 2010-07-11 5:02 ` Kyle Moffett 2010-07-11 5:02 ` Kyle Moffett 2010-07-11 5:02 ` Kyle Moffett 2010-07-11 5:12 ` Casey Schaufler 2010-07-11 5:12 ` Casey Schaufler 2010-07-11 5:12 ` Casey Schaufler 2010-07-12 14:36 ` Stephen Smalley 2010-07-12 14:36 ` Stephen Smalley 2010-07-17 0:09 ` Kyle Moffett 2010-07-17 0:09 ` Kyle Moffett 2010-07-17 0:09 ` Kyle Moffett 2010-07-17 0:09 ` Kyle Moffett 2010-07-07 14:31 ` [PATCH 07/10] NFSv4: Introduce new label structure David P. Quigley 2010-07-07 14:31 ` David P. Quigley 2010-07-07 16:01 ` Chuck Lever 2010-07-07 16:21 ` Casey Schaufler 2010-07-07 16:21 ` Casey Schaufler 2010-07-07 16:21 ` Casey Schaufler 2010-07-07 16:24 ` David P. Quigley 2010-07-07 16:24 ` David P. Quigley 2010-07-07 16:24 ` David P. Quigley 2010-07-07 17:42 ` Chuck Lever 2010-07-07 17:42 ` Chuck Lever 2010-07-07 16:22 ` David P. Quigley 2010-07-07 16:22 ` David P. Quigley 2010-07-07 16:22 ` David P. Quigley 2010-07-07 17:49 ` Chuck Lever 2010-07-07 18:11 ` David P. Quigley 2010-07-07 18:11 ` David P. Quigley 2010-07-07 14:31 ` [PATCH 08/10] NFS: Client implementation of Labeled-NFS David P. Quigley 2010-07-07 14:31 ` David P. Quigley 2010-07-07 14:31 ` [PATCH 09/10] NFS: Extend NFS xattr handlers to accept the security namespace David P. Quigley 2010-07-07 14:31 ` David P. Quigley 2010-07-07 14:31 ` [PATCH 10/10] NFSD: Server implementation of MAC Labeling David P. Quigley 2010-07-07 14:31 ` David P. Quigley 2010-07-07 17:21 ` J. Bruce Fields 2010-07-07 18:03 ` David P. Quigley 2010-07-07 18:03 ` David P. Quigley 2010-07-07 18:03 ` David P. Quigley 2010-07-07 19:24 ` J. Bruce Fields 2010-07-08 13:27 ` David P. Quigley [this message] 2010-07-08 13:27 ` David P. Quigley -- strict thread matches above, loose matches on Subject: below -- 2010-06-08 16:22 Labeled-NFS: Security Label support in NFSv4 David P. Quigley 2010-06-08 16:22 ` [PATCH 10/10] NFSD: Server implementation of MAC Labeling David P. Quigley 2010-06-08 16:22 ` David P. Quigley 2010-06-08 16:22 ` David P. 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=1278595657.2494.182.camel@moss-terrapins.epoch.ncsc.mil \ --to=dpquigl@tycho.nsa.gov \ --cc=bfields@fieldses.org \ --cc=casey@schaufler-ca.com \ --cc=hch@infradead.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nfs@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=matthew.dodd@sparta.com \ --cc=sds@tycho.nsa.gov \ --cc=selinux@tycho.nsa.gov \ --cc=trond.myklebust@fys.uio.no \ --cc=viro@zeniv.linux.org.uk \ /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: linkBe 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.