| Message ID | 50A31EF5.1050801@davequigley.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Nov 13, 2012 at 11:32:53PM -0500, Dave Quigley wrote: > On 11/13/2012 7:55 AM, Steve Dickson wrote: > > > > > >On 12/11/12 20:39, Dave Quigley wrote: > >>If you're ok with non Fedora kernel images I can try to put up a tree either tonight or tomorrow with the patches that you just need to build and install. That plus the one patch for nfs-utils should make everything work. > >I'm good with that.... > > > >steved. > > > > Ok so if you go to http://www.selinuxproject.org/git you will see a > repo for lnfs and lnfs-patchset. The instructions at > http://www.selinuxproject.org/page/Labeled_NFS give you a better > indication on how to pull the trees. I've attached a patch for NFS > utils which gives support for security_label/nosecurity_label in > your /etc/exports file. Do we need an export option? Is there any reason not to make the feature available whenever there's support available for it? --b. > I've also attached a script called setup > which should build a test directory called /export with a copy of > /var/www under it which should be labeled properly. It does all the > proper SELinux commands to make sure labeling is correct. Once you > have that setup just mount -t nfs localhost:/ /mnt/lnfs (or wherever > you want) and you should be good to go. Just ls -Z in /mnt/lnfs/var > and check to make sure the labels are the same as /export/var. It > should have the labels showing up in the network transfer. If you > have any problems just let me know and I can try to help figure them > out. > > Dave > >From da84919c6957090cd961bb4ce40753820312a845 Mon Sep 17 00:00:00 2001 > From: Dave Quigley <dpquigl@taiga.selinuxproject.org> > Date: Fri, 18 Sep 2009 08:53:58 -0700 > Subject: [PATCH] Add support to specify which exports will provide Labeled NFS support. > > diff --git a/support/include/nfs/export.h b/support/include/nfs/export.h > index 1547a87..b8e2fb0 100644 > --- a/support/include/nfs/export.h > +++ b/support/include/nfs/export.h > @@ -17,7 +17,8 @@ > #define NFSEXP_ALLSQUASH 0x0008 > #define NFSEXP_ASYNC 0x0010 > #define NFSEXP_GATHERED_WRITES 0x0020 > -/* 40, 80, 100 unused */ > +#define NFSEXP_SECURITY_LABEL 0x0040 /* Support MAC attribute */ > +/* 80, 100 unused */ > #define NFSEXP_NOHIDE 0x0200 > #define NFSEXP_NOSUBTREECHECK 0x0400 > #define NFSEXP_NOAUTHNLM 0x0800 > diff --git a/support/nfs/exports.c b/support/nfs/exports.c > index a93941c..8965c8d 100644 > --- a/support/nfs/exports.c > +++ b/support/nfs/exports.c > @@ -239,6 +239,8 @@ putexportent(struct exportent *ep) > fprintf(fp, "%ssync,", (ep->e_flags & NFSEXP_ASYNC)? "a" : ""); > fprintf(fp, "%swdelay,", (ep->e_flags & NFSEXP_GATHERED_WRITES)? > "" : "no_"); > + fprintf(fp, "%ssecurity_label,", (ep->e_flags & NFSEXP_SECURITY_LABEL)? > + "" : "no"); > fprintf(fp, "%shide,", (ep->e_flags & NFSEXP_NOHIDE)? > "no" : ""); > fprintf(fp, "%scrossmnt,", (ep->e_flags & NFSEXP_CROSSMOUNT)? > @@ -531,6 +533,10 @@ parseopts(char *cp, struct exportent *ep, int warn, int *had_subtree_opt_ptr) > setflags(NFSEXP_GATHERED_WRITES, active, ep); > else if (!strcmp(opt, "no_wdelay")) > clearflags(NFSEXP_GATHERED_WRITES, active, ep); > + else if (strcmp(opt, "security_label") == 0) > + ep->e_flags |= NFSEXP_SECURITY_LABEL; > + else if (strcmp(opt, "nosecurity_label") == 0) > + ep->e_flags &= ~NFSEXP_SECURITY_LABEL; > else if (strcmp(opt, "root_squash") == 0) > setflags(NFSEXP_ROOTSQUASH, active, ep); > else if (!strcmp(opt, "no_root_squash")) > diff --git a/utils/exportfs/exportfs.c b/utils/exportfs/exportfs.c > index b78957f..6434825 100644 > --- a/utils/exportfs/exportfs.c > +++ b/utils/exportfs/exportfs.c > @@ -531,6 +531,8 @@ dump(int verbose) > c = dumpopt(c, "async"); > if (ep->e_flags & NFSEXP_GATHERED_WRITES) > c = dumpopt(c, "wdelay"); > + if (ep->e_flags & NFSEXP_SECURITY_LABEL) > + c = dumpopt(c, "security_label"); > if (ep->e_flags & NFSEXP_NOHIDE) > c = dumpopt(c, "nohide"); > if (ep->e_flags & NFSEXP_CROSSMOUNT) > #!/bin/bash > mkdir /export > semanage fcontext -a -t mnt_t /export > mkdir /export/var > cp -R /var/www /export/var > semanage fcontext -ae /var /export/var > restorecon -R /export > > echo "/export *(rw,fsid=0,sec=unix,security_label,insecure,no_subtree_check,sync, no_root_squash)" >> /etc/exports > systemctl restart nfs-server.service -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/14/2012 08:45, J. Bruce Fields wrote: > On Tue, Nov 13, 2012 at 11:32:53PM -0500, Dave Quigley wrote: >> On 11/13/2012 7:55 AM, Steve Dickson wrote: >> > >> > >> >On 12/11/12 20:39, Dave Quigley wrote: >> >>If you're ok with non Fedora kernel images I can try to put up a >> tree either tonight or tomorrow with the patches that you just need to >> build and install. That plus the one patch for nfs-utils should make >> everything work. >> >I'm good with that.... >> > >> >steved. >> > >> >> Ok so if you go to http://www.selinuxproject.org/git you will see a >> repo for lnfs and lnfs-patchset. The instructions at >> http://www.selinuxproject.org/page/Labeled_NFS give you a better >> indication on how to pull the trees. I've attached a patch for NFS >> utils which gives support for security_label/nosecurity_label in >> your /etc/exports file. > > Do we need an export option? Is there any reason not to make the > feature available whenever there's support available for it? > > --b. > >> I've also attached a script called setup >> which should build a test directory called /export with a copy of >> /var/www under it which should be labeled properly. It does all the >> proper SELinux commands to make sure labeling is correct. Once you >> have that setup just mount -t nfs localhost:/ /mnt/lnfs (or wherever >> you want) and you should be good to go. Just ls -Z in /mnt/lnfs/var >> and check to make sure the labels are the same as /export/var. It >> should have the labels showing up in the network transfer. If you >> have any problems just let me know and I can try to help figure them >> out. >> >> Dave > >> >From da84919c6957090cd961bb4ce40753820312a845 Mon Sep 17 00:00:00 >> 2001 >> From: Dave Quigley <dpquigl@taiga.selinuxproject.org> >> Date: Fri, 18 Sep 2009 08:53:58 -0700 >> Subject: [PATCH] Add support to specify which exports will provide >> Labeled NFS support. >> >> diff --git a/support/include/nfs/export.h >> b/support/include/nfs/export.h >> index 1547a87..b8e2fb0 100644 >> --- a/support/include/nfs/export.h >> +++ b/support/include/nfs/export.h >> @@ -17,7 +17,8 @@ >> #define NFSEXP_ALLSQUASH 0x0008 >> #define NFSEXP_ASYNC 0x0010 >> #define NFSEXP_GATHERED_WRITES 0x0020 >> -/* 40, 80, 100 unused */ >> +#define NFSEXP_SECURITY_LABEL 0x0040 /* Support MAC attribute */ >> +/* 80, 100 unused */ >> #define NFSEXP_NOHIDE 0x0200 >> #define NFSEXP_NOSUBTREECHECK 0x0400 >> #define NFSEXP_NOAUTHNLM 0x0800 >> diff --git a/support/nfs/exports.c b/support/nfs/exports.c >> index a93941c..8965c8d 100644 >> --- a/support/nfs/exports.c >> +++ b/support/nfs/exports.c >> @@ -239,6 +239,8 @@ putexportent(struct exportent *ep) >> fprintf(fp, "%ssync,", (ep->e_flags & NFSEXP_ASYNC)? "a" : ""); >> fprintf(fp, "%swdelay,", (ep->e_flags & NFSEXP_GATHERED_WRITES)? >> "" : "no_"); >> + fprintf(fp, "%ssecurity_label,", (ep->e_flags & >> NFSEXP_SECURITY_LABEL)? >> + "" : "no"); >> fprintf(fp, "%shide,", (ep->e_flags & NFSEXP_NOHIDE)? >> "no" : ""); >> fprintf(fp, "%scrossmnt,", (ep->e_flags & NFSEXP_CROSSMOUNT)? >> @@ -531,6 +533,10 @@ parseopts(char *cp, struct exportent *ep, int >> warn, int *had_subtree_opt_ptr) >> setflags(NFSEXP_GATHERED_WRITES, active, ep); >> else if (!strcmp(opt, "no_wdelay")) >> clearflags(NFSEXP_GATHERED_WRITES, active, ep); >> + else if (strcmp(opt, "security_label") == 0) >> + ep->e_flags |= NFSEXP_SECURITY_LABEL; >> + else if (strcmp(opt, "nosecurity_label") == 0) >> + ep->e_flags &= ~NFSEXP_SECURITY_LABEL; >> else if (strcmp(opt, "root_squash") == 0) >> setflags(NFSEXP_ROOTSQUASH, active, ep); >> else if (!strcmp(opt, "no_root_squash")) >> diff --git a/utils/exportfs/exportfs.c b/utils/exportfs/exportfs.c >> index b78957f..6434825 100644 >> --- a/utils/exportfs/exportfs.c >> +++ b/utils/exportfs/exportfs.c >> @@ -531,6 +531,8 @@ dump(int verbose) >> c = dumpopt(c, "async"); >> if (ep->e_flags & NFSEXP_GATHERED_WRITES) >> c = dumpopt(c, "wdelay"); >> + if (ep->e_flags & NFSEXP_SECURITY_LABEL) >> + c = dumpopt(c, "security_label"); >> if (ep->e_flags & NFSEXP_NOHIDE) >> c = dumpopt(c, "nohide"); >> if (ep->e_flags & NFSEXP_CROSSMOUNT) > >> #!/bin/bash >> mkdir /export >> semanage fcontext -a -t mnt_t /export >> mkdir /export/var >> cp -R /var/www /export/var >> semanage fcontext -ae /var /export/var >> restorecon -R /export >> >> echo "/export >> *(rw,fsid=0,sec=unix,security_label,insecure,no_subtree_check,sync, >> no_root_squash)" >> /etc/exports >> systemctl restart nfs-server.service I guess we could build it in but I figured an export option allowed someone to turn off security labeling support if they didn't want it on that export. What happens to clients when the server returns a cap that they don't support? Do they mask the bits out? -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/13/2012 23:32, Dave Quigley wrote: > On 11/13/2012 7:55 AM, Steve Dickson wrote: >> >> >> On 12/11/12 20:39, Dave Quigley wrote: >>> If you're ok with non Fedora kernel images I can try to put up a >>> tree either tonight or tomorrow with the patches that you just need >>> to build and install. That plus the one patch for nfs-utils should >>> make everything work. >> I'm good with that.... >> >> steved. >> > > Ok so if you go to http://www.selinuxproject.org/git you will see a > repo for lnfs and lnfs-patchset. The instructions at > http://www.selinuxproject.org/page/Labeled_NFS give you a better > indication on how to pull the trees. I've attached a patch for NFS > utils which gives support for security_label/nosecurity_label in your > /etc/exports file. I've also attached a script called setup which > should build a test directory called /export with a copy of /var/www > under it which should be labeled properly. It does all the proper > SELinux commands to make sure labeling is correct. Once you have that > setup just mount -t nfs localhost:/ /mnt/lnfs (or wherever you want) > and you should be good to go. Just ls -Z in /mnt/lnfs/var and check > to > make sure the labels are the same as /export/var. It should have the > labels showing up in the network transfer. If you have any problems > just let me know and I can try to help figure them out. > > Dave If you want to run the testsuite we used Serge has a repo on the git page above for the selinux-testsuite. Just copy it onto the nfs export and follow the instructions in the readme. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 14, 2012 at 08:50:17AM -0500, David Quigley wrote: > On 11/14/2012 08:45, J. Bruce Fields wrote: > >On Tue, Nov 13, 2012 at 11:32:53PM -0500, Dave Quigley wrote: > >>Ok so if you go to http://www.selinuxproject.org/git you will see a > >>repo for lnfs and lnfs-patchset. The instructions at > >>http://www.selinuxproject.org/page/Labeled_NFS give you a better > >>indication on how to pull the trees. I've attached a patch for NFS > >>utils which gives support for security_label/nosecurity_label in > >>your /etc/exports file. > > > >Do we need an export option? Is there any reason not to make the > >feature available whenever there's support available for it? > > I guess we could build it in but I figured an export option allowed > someone to turn off security labeling support if they didn't want it > on that export. What happens to clients when the server returns a > cap that they don't support? Do they mask the bits out? Yeah, they should just ignore it. While this is still experimental it's still nice to have a way to turn this on and off at runtime so people can experiment without having to have it on for everyone all the time. But nfsd_supported_minorversion should be sufficient for that. (I don't think your patches actually dealt yet with the fact that this is part of minor version 2? Another for the todo list.) --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/14/2012 08:59, J. Bruce Fields wrote: > On Wed, Nov 14, 2012 at 08:50:17AM -0500, David Quigley wrote: >> On 11/14/2012 08:45, J. Bruce Fields wrote: >> >On Tue, Nov 13, 2012 at 11:32:53PM -0500, Dave Quigley wrote: >> >>Ok so if you go to http://www.selinuxproject.org/git you will see >> a >> >>repo for lnfs and lnfs-patchset. The instructions at >> >>http://www.selinuxproject.org/page/Labeled_NFS give you a better >> >>indication on how to pull the trees. I've attached a patch for NFS >> >>utils which gives support for security_label/nosecurity_label in >> >>your /etc/exports file. >> > >> >Do we need an export option? Is there any reason not to make the >> >feature available whenever there's support available for it? >> >> I guess we could build it in but I figured an export option allowed >> someone to turn off security labeling support if they didn't want it >> on that export. What happens to clients when the server returns a >> cap that they don't support? Do they mask the bits out? > > Yeah, they should just ignore it. > > While this is still experimental it's still nice to have a way to > turn > this on and off at runtime so people can experiment without having to > have it on for everyone all the time. But > nfsd_supported_minorversion > should be sufficient for that. > > (I don't think your patches actually dealt yet with the fact that > this > is part of minor version 2? Another for the todo list.) > > --b. Hmm... I'll have to look at the patches again to find out. Its been so long since I worked on these full time that I have to go back and check quite a bit. Luckily since i put the tree up for Trond last night I should be able to look at them while at work. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/14/2012 08:59, J. Bruce Fields wrote: > On Wed, Nov 14, 2012 at 08:50:17AM -0500, David Quigley wrote: >> On 11/14/2012 08:45, J. Bruce Fields wrote: >> >On Tue, Nov 13, 2012 at 11:32:53PM -0500, Dave Quigley wrote: >> >>Ok so if you go to http://www.selinuxproject.org/git you will see >> a >> >>repo for lnfs and lnfs-patchset. The instructions at >> >>http://www.selinuxproject.org/page/Labeled_NFS give you a better >> >>indication on how to pull the trees. I've attached a patch for NFS >> >>utils which gives support for security_label/nosecurity_label in >> >>your /etc/exports file. >> > >> >Do we need an export option? Is there any reason not to make the >> >feature available whenever there's support available for it? >> >> I guess we could build it in but I figured an export option allowed >> someone to turn off security labeling support if they didn't want it >> on that export. What happens to clients when the server returns a >> cap that they don't support? Do they mask the bits out? > > Yeah, they should just ignore it. > > While this is still experimental it's still nice to have a way to > turn > this on and off at runtime so people can experiment without having to > have it on for everyone all the time. But > nfsd_supported_minorversion > should be sufficient for that. > > (I don't think your patches actually dealt yet with the fact that > this > is part of minor version 2? Another for the todo list.) > > --b. If we use nfsd_supported_minorversion which I'm guessing is an export option what happens if someone wants to use other 4.2 features but not labeling? I'll switch it over if you guys want it done that way, I think though that this provides more flexibility. Although anything that makes me carry around fewer patches is good in my book. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 14, 2012 at 09:04:18AM -0500, David Quigley wrote: > On 11/14/2012 08:59, J. Bruce Fields wrote: > >On Wed, Nov 14, 2012 at 08:50:17AM -0500, David Quigley wrote: > >>On 11/14/2012 08:45, J. Bruce Fields wrote: > >>>On Tue, Nov 13, 2012 at 11:32:53PM -0500, Dave Quigley wrote: > >>>>Ok so if you go to http://www.selinuxproject.org/git you will > >>see a > >>>>repo for lnfs and lnfs-patchset. The instructions at > >>>>http://www.selinuxproject.org/page/Labeled_NFS give you a better > >>>>indication on how to pull the trees. I've attached a patch for NFS > >>>>utils which gives support for security_label/nosecurity_label in > >>>>your /etc/exports file. > >>> > >>>Do we need an export option? Is there any reason not to make the > >>>feature available whenever there's support available for it? > >> > >>I guess we could build it in but I figured an export option allowed > >>someone to turn off security labeling support if they didn't want it > >>on that export. What happens to clients when the server returns a > >>cap that they don't support? Do they mask the bits out? > > > >Yeah, they should just ignore it. > > > >While this is still experimental it's still nice to have a way to > >turn > >this on and off at runtime so people can experiment without having to > >have it on for everyone all the time. But > >nfsd_supported_minorversion > >should be sufficient for that. > > > >(I don't think your patches actually dealt yet with the fact that > >this > >is part of minor version 2? Another for the todo list.) > > > >--b. > > If we use nfsd_supported_minorversion which I'm guessing is an > export option That's just a variable in the code. It's controlled by /proc/fs/nfsd/versions. > what happens if someone wants to use other 4.2 > features but not labeling? We'll cross that bridge when we come to it, maybe by adding some new global paramater. There's no reason this really needs to be per-export, is there? --b. > I'll switch it over if you guys want it > done that way, I think though that this provides more flexibility. > Although anything that makes me carry around fewer patches is good > in my book. > > Dave -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/14/2012 09:24, J. Bruce Fields wrote: > On Wed, Nov 14, 2012 at 09:04:18AM -0500, David Quigley wrote: >> On 11/14/2012 08:59, J. Bruce Fields wrote: >> >On Wed, Nov 14, 2012 at 08:50:17AM -0500, David Quigley wrote: >> >>On 11/14/2012 08:45, J. Bruce Fields wrote: >> >>>On Tue, Nov 13, 2012 at 11:32:53PM -0500, Dave Quigley wrote: >> >>>>Ok so if you go to http://www.selinuxproject.org/git you will >> >>see a >> >>>>repo for lnfs and lnfs-patchset. The instructions at >> >>>>http://www.selinuxproject.org/page/Labeled_NFS give you a better >> >>>>indication on how to pull the trees. I've attached a patch for >> NFS >> >>>>utils which gives support for security_label/nosecurity_label in >> >>>>your /etc/exports file. >> >>> >> >>>Do we need an export option? Is there any reason not to make the >> >>>feature available whenever there's support available for it? >> >> >> >>I guess we could build it in but I figured an export option >> allowed >> >>someone to turn off security labeling support if they didn't want >> it >> >>on that export. What happens to clients when the server returns a >> >>cap that they don't support? Do they mask the bits out? >> > >> >Yeah, they should just ignore it. >> > >> >While this is still experimental it's still nice to have a way to >> >turn >> >this on and off at runtime so people can experiment without having >> to >> >have it on for everyone all the time. But >> >nfsd_supported_minorversion >> >should be sufficient for that. >> > >> >(I don't think your patches actually dealt yet with the fact that >> >this >> >is part of minor version 2? Another for the todo list.) >> > >> >--b. >> >> If we use nfsd_supported_minorversion which I'm guessing is an >> export option > > That's just a variable in the code. It's controlled by > /proc/fs/nfsd/versions. > >> what happens if someone wants to use other 4.2 >> features but not labeling? > > We'll cross that bridge when we come to it, maybe by adding some new > global paramater. > > There's no reason this really needs to be per-export, is there? > > --b. At the moment I can't really think of a reason to have it be per-export. I think we need a new LSM patch though to determine if the LSM supports labeling over NFS unless Steve can think of a better way to tell if the LSM supports labeling. > >> I'll switch it over if you guys want it >> done that way, I think though that this provides more flexibility. >> Although anything that makes me carry around fewer patches is good >> in my book. >> >> Dave -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/14/2012 6:30 AM, David Quigley wrote: > On 11/14/2012 09:24, J. Bruce Fields wrote: >> On Wed, Nov 14, 2012 at 09:04:18AM -0500, David Quigley wrote: >>> On 11/14/2012 08:59, J. Bruce Fields wrote: >>> >On Wed, Nov 14, 2012 at 08:50:17AM -0500, David Quigley wrote: >>> >>On 11/14/2012 08:45, J. Bruce Fields wrote: >>> >>>On Tue, Nov 13, 2012 at 11:32:53PM -0500, Dave Quigley wrote: >>> >>>>Ok so if you go to http://www.selinuxproject.org/git you will >>> >>see a >>> >>>>repo for lnfs and lnfs-patchset. The instructions at >>> >>>>http://www.selinuxproject.org/page/Labeled_NFS give you a better >>> >>>>indication on how to pull the trees. I've attached a patch for NFS >>> >>>>utils which gives support for security_label/nosecurity_label in >>> >>>>your /etc/exports file. >>> >>> >>> >>>Do we need an export option? Is there any reason not to make the >>> >>>feature available whenever there's support available for it? >>> >> >>> >>I guess we could build it in but I figured an export option allowed >>> >>someone to turn off security labeling support if they didn't want it >>> >>on that export. What happens to clients when the server returns a >>> >>cap that they don't support? Do they mask the bits out? >>> > >>> >Yeah, they should just ignore it. >>> > >>> >While this is still experimental it's still nice to have a way to >>> >turn >>> >this on and off at runtime so people can experiment without having to >>> >have it on for everyone all the time. But >>> >nfsd_supported_minorversion >>> >should be sufficient for that. >>> > >>> >(I don't think your patches actually dealt yet with the fact that >>> >this >>> >is part of minor version 2? Another for the todo list.) >>> > >>> >--b. >>> >>> If we use nfsd_supported_minorversion which I'm guessing is an >>> export option >> >> That's just a variable in the code. It's controlled by >> /proc/fs/nfsd/versions. >> >>> what happens if someone wants to use other 4.2 >>> features but not labeling? >> >> We'll cross that bridge when we come to it, maybe by adding some new >> global paramater. >> >> There's no reason this really needs to be per-export, is there? >> >> --b. > > At the moment I can't really think of a reason to have it be > per-export. I think we need a new LSM patch though to determine if the > LSM supports labeling over NFS unless Steve can think of a better way > to tell if the LSM supports labeling. If the LSM has a secid_to_secctx hook it supports labeling. Today that's SELinux and Smack. You already have support in for SELinux, and providing Smack's review and possibly updates is #2 on my gotta do list. On the whole, I think that, except for the fundamental philosophical difference between label support and xattr support, it should be a simple matter to get support in for any LSM that has secid_to_secctx. But I'm still working on the review. > > >> >>> I'll switch it over if you guys want it >>> done that way, I think though that this provides more flexibility. >>> Although anything that makes me carry around fewer patches is good >>> in my book. >>> >>> Dave > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/15/2012 11:00, Casey Schaufler wrote: > On 11/14/2012 6:30 AM, David Quigley wrote: >> On 11/14/2012 09:24, J. Bruce Fields wrote: >>> On Wed, Nov 14, 2012 at 09:04:18AM -0500, David Quigley wrote: >>>> On 11/14/2012 08:59, J. Bruce Fields wrote: >>>> >On Wed, Nov 14, 2012 at 08:50:17AM -0500, David Quigley wrote: >>>> >>On 11/14/2012 08:45, J. Bruce Fields wrote: >>>> >>>On Tue, Nov 13, 2012 at 11:32:53PM -0500, Dave Quigley wrote: >>>> >>>>Ok so if you go to http://www.selinuxproject.org/git you will >>>> >>see a >>>> >>>>repo for lnfs and lnfs-patchset. The instructions at >>>> >>>>http://www.selinuxproject.org/page/Labeled_NFS give you a >>>> better >>>> >>>>indication on how to pull the trees. I've attached a patch for >>>> NFS >>>> >>>>utils which gives support for security_label/nosecurity_label >>>> in >>>> >>>>your /etc/exports file. >>>> >>> >>>> >>>Do we need an export option? Is there any reason not to make >>>> the >>>> >>>feature available whenever there's support available for it? >>>> >> >>>> >>I guess we could build it in but I figured an export option >>>> allowed >>>> >>someone to turn off security labeling support if they didn't >>>> want it >>>> >>on that export. What happens to clients when the server returns >>>> a >>>> >>cap that they don't support? Do they mask the bits out? >>>> > >>>> >Yeah, they should just ignore it. >>>> > >>>> >While this is still experimental it's still nice to have a way to >>>> >turn >>>> >this on and off at runtime so people can experiment without >>>> having to >>>> >have it on for everyone all the time. But >>>> >nfsd_supported_minorversion >>>> >should be sufficient for that. >>>> > >>>> >(I don't think your patches actually dealt yet with the fact that >>>> >this >>>> >is part of minor version 2? Another for the todo list.) >>>> > >>>> >--b. >>>> >>>> If we use nfsd_supported_minorversion which I'm guessing is an >>>> export option >>> >>> That's just a variable in the code. It's controlled by >>> /proc/fs/nfsd/versions. >>> >>>> what happens if someone wants to use other 4.2 >>>> features but not labeling? >>> >>> We'll cross that bridge when we come to it, maybe by adding some >>> new >>> global paramater. >>> >>> There's no reason this really needs to be per-export, is there? >>> >>> --b. >> >> At the moment I can't really think of a reason to have it be >> per-export. I think we need a new LSM patch though to determine if >> the >> LSM supports labeling over NFS unless Steve can think of a better >> way >> to tell if the LSM supports labeling. > > If the LSM has a secid_to_secctx hook it supports labeling. > Today that's SELinux and Smack. You already have support in > for SELinux, and providing Smack's review and possibly updates > is #2 on my gotta do list. On the whole, I think that, except > for the fundamental philosophical difference between label > support and xattr support, it should be a simple matter to > get support in for any LSM that has secid_to_secctx. > > But I'm still working on the review. > I believe SMACK already works out of the box since we abstracted the call to obtain labels and your implementation currently works. The call that is needed is not secid_to_secctx but inode_getsecctx. You asked for this because SMACK labels can span multiple xattrs. I don't think its right to expect NFS to poke around the security structure to check if there is a valid hook(and it isn't really possible either). Maybe we can have an LSM hook where the LSM categorizes itself and returns a value and if the value it returns is label based then NFS can use it. >> >> >>> >>>> I'll switch it over if you guys want it >>>> done that way, I think though that this provides more flexibility. >>>> Although anything that makes me carry around fewer patches is good >>>> in my book. >>>> >>>> Dave >> >> -- >> To unsubscribe from this list: send the line "unsubscribe >> linux-security-module" in >> the body of a message to majordomo@vger.kernel.org >> 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@tycho.nsa.gov 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/15/2012 12:28 PM, David Quigley wrote: > On 11/15/2012 11:00, Casey Schaufler wrote: >> On 11/14/2012 6:30 AM, David Quigley wrote: >>> On 11/14/2012 09:24, J. Bruce Fields wrote: >>>> On Wed, Nov 14, 2012 at 09:04:18AM -0500, David Quigley wrote: >>>>> On 11/14/2012 08:59, J. Bruce Fields wrote: >>>>> >On Wed, Nov 14, 2012 at 08:50:17AM -0500, David Quigley wrote: >>>>> >>On 11/14/2012 08:45, J. Bruce Fields wrote: >>>>> >>>On Tue, Nov 13, 2012 at 11:32:53PM -0500, Dave Quigley wrote: >>>>> >>>>Ok so if you go to http://www.selinuxproject.org/git you will >>>>> >>see a >>>>> >>>>repo for lnfs and lnfs-patchset. The instructions at >>>>> >>>>http://www.selinuxproject.org/page/Labeled_NFS give you a better >>>>> >>>>indication on how to pull the trees. I've attached a patch for >>>>> NFS >>>>> >>>>utils which gives support for security_label/nosecurity_label in >>>>> >>>>your /etc/exports file. >>>>> >>> >>>>> >>>Do we need an export option? Is there any reason not to make the >>>>> >>>feature available whenever there's support available for it? >>>>> >> >>>>> >>I guess we could build it in but I figured an export option allowed >>>>> >>someone to turn off security labeling support if they didn't >>>>> want it >>>>> >>on that export. What happens to clients when the server returns a >>>>> >>cap that they don't support? Do they mask the bits out? >>>>> > >>>>> >Yeah, they should just ignore it. >>>>> > >>>>> >While this is still experimental it's still nice to have a way to >>>>> >turn >>>>> >this on and off at runtime so people can experiment without >>>>> having to >>>>> >have it on for everyone all the time. But >>>>> >nfsd_supported_minorversion >>>>> >should be sufficient for that. >>>>> > >>>>> >(I don't think your patches actually dealt yet with the fact that >>>>> >this >>>>> >is part of minor version 2? Another for the todo list.) >>>>> > >>>>> >--b. >>>>> >>>>> If we use nfsd_supported_minorversion which I'm guessing is an >>>>> export option >>>> >>>> That's just a variable in the code. It's controlled by >>>> /proc/fs/nfsd/versions. >>>> >>>>> what happens if someone wants to use other 4.2 >>>>> features but not labeling? >>>> >>>> We'll cross that bridge when we come to it, maybe by adding some new >>>> global paramater. >>>> >>>> There's no reason this really needs to be per-export, is there? >>>> >>>> --b. >>> >>> At the moment I can't really think of a reason to have it be >>> per-export. I think we need a new LSM patch though to determine if the >>> LSM supports labeling over NFS unless Steve can think of a better way >>> to tell if the LSM supports labeling. >> >> If the LSM has a secid_to_secctx hook it supports labeling. >> Today that's SELinux and Smack. You already have support in >> for SELinux, and providing Smack's review and possibly updates >> is #2 on my gotta do list. On the whole, I think that, except >> for the fundamental philosophical difference between label >> support and xattr support, it should be a simple matter to >> get support in for any LSM that has secid_to_secctx. >> >> But I'm still working on the review. >> > > I believe SMACK already works out of the box since we abstracted the > call to obtain labels and your implementation currently works. I'm looking to do a little verification. I hate assuming that something will work only to discover otherwise in the wild. > The call that is needed is not secid_to_secctx but inode_getsecctx. I was pointing out that secid_to_secctx pretty well defines that the LSM is using labels. > You asked for this because SMACK labels can span multiple xattrs. I > don't think its right to expect NFS to poke around the security > structure to check if there is a valid hook(and it isn't really > possible either). Yeah, I can see that. > Maybe we can have an LSM hook where the LSM categorizes itself and > returns a value and if the value it returns is label based then NFS > can use it. I'm not sure what the proposed hook would be for except to identify it as concerned with nfs. Perhaps the hook could return the names of attributes that it wants nfs to provide. > >>> >>> >>>> >>>>> I'll switch it over if you guys want it >>>>> done that way, I think though that this provides more flexibility. >>>>> Although anything that makes me carry around fewer patches is good >>>>> in my book. >>>>> >>>>> Dave >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe >>> linux-security-module" in >>> the body of a message to majordomo@vger.kernel.org >>> 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@tycho.nsa.gov 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/15/2012 22:34, Casey Schaufler wrote: > On 11/15/2012 12:28 PM, David Quigley wrote: >> On 11/15/2012 11:00, Casey Schaufler wrote: >>> On 11/14/2012 6:30 AM, David Quigley wrote: >>>> On 11/14/2012 09:24, J. Bruce Fields wrote: >>>>> On Wed, Nov 14, 2012 at 09:04:18AM -0500, David Quigley wrote: >>>>>> On 11/14/2012 08:59, J. Bruce Fields wrote: >>>>>> >On Wed, Nov 14, 2012 at 08:50:17AM -0500, David Quigley wrote: >>>>>> >>On 11/14/2012 08:45, J. Bruce Fields wrote: >>>>>> >>>On Tue, Nov 13, 2012 at 11:32:53PM -0500, Dave Quigley wrote: >>>>>> >>>>Ok so if you go to http://www.selinuxproject.org/git you >>>>>> will >>>>>> >>see a >>>>>> >>>>repo for lnfs and lnfs-patchset. The instructions at >>>>>> >>>>http://www.selinuxproject.org/page/Labeled_NFS give you a >>>>>> better >>>>>> >>>>indication on how to pull the trees. I've attached a patch >>>>>> for >>>>>> NFS >>>>>> >>>>utils which gives support for >>>>>> security_label/nosecurity_label in >>>>>> >>>>your /etc/exports file. >>>>>> >>> >>>>>> >>>Do we need an export option? Is there any reason not to make >>>>>> the >>>>>> >>>feature available whenever there's support available for it? >>>>>> >> >>>>>> >>I guess we could build it in but I figured an export option >>>>>> allowed >>>>>> >>someone to turn off security labeling support if they didn't >>>>>> want it >>>>>> >>on that export. What happens to clients when the server >>>>>> returns a >>>>>> >>cap that they don't support? Do they mask the bits out? >>>>>> > >>>>>> >Yeah, they should just ignore it. >>>>>> > >>>>>> >While this is still experimental it's still nice to have a way >>>>>> to >>>>>> >turn >>>>>> >this on and off at runtime so people can experiment without >>>>>> having to >>>>>> >have it on for everyone all the time. But >>>>>> >nfsd_supported_minorversion >>>>>> >should be sufficient for that. >>>>>> > >>>>>> >(I don't think your patches actually dealt yet with the fact >>>>>> that >>>>>> >this >>>>>> >is part of minor version 2? Another for the todo list.) >>>>>> > >>>>>> >--b. >>>>>> >>>>>> If we use nfsd_supported_minorversion which I'm guessing is an >>>>>> export option >>>>> >>>>> That's just a variable in the code. It's controlled by >>>>> /proc/fs/nfsd/versions. >>>>> >>>>>> what happens if someone wants to use other 4.2 >>>>>> features but not labeling? >>>>> >>>>> We'll cross that bridge when we come to it, maybe by adding some >>>>> new >>>>> global paramater. >>>>> >>>>> There's no reason this really needs to be per-export, is there? >>>>> >>>>> --b. >>>> >>>> At the moment I can't really think of a reason to have it be >>>> per-export. I think we need a new LSM patch though to determine if >>>> the >>>> LSM supports labeling over NFS unless Steve can think of a better >>>> way >>>> to tell if the LSM supports labeling. >>> >>> If the LSM has a secid_to_secctx hook it supports labeling. >>> Today that's SELinux and Smack. You already have support in >>> for SELinux, and providing Smack's review and possibly updates >>> is #2 on my gotta do list. On the whole, I think that, except >>> for the fundamental philosophical difference between label >>> support and xattr support, it should be a simple matter to >>> get support in for any LSM that has secid_to_secctx. >>> >>> But I'm still working on the review. >>> >> >> I believe SMACK already works out of the box since we abstracted the >> call to obtain labels and your implementation currently works. > > I'm looking to do a little verification. I hate assuming that > something > will work only to discover otherwise in the wild. > >> The call that is needed is not secid_to_secctx but inode_getsecctx. > > I was pointing out that secid_to_secctx pretty well defines that the > LSM > is using labels. > >> You asked for this because SMACK labels can span multiple xattrs. I >> don't think its right to expect NFS to poke around the security >> structure to check if there is a valid hook(and it isn't really >> possible either). > > Yeah, I can see that. > >> Maybe we can have an LSM hook where the LSM categorizes itself and >> returns a value and if the value it returns is label based then NFS >> can use it. > > I'm not sure what the proposed hook would be for except to identify > it > as concerned with nfs. Perhaps the hook could return the names of > attributes that it wants nfs to provide. > I'm not quite sure what you're proposing? I'm sure someone would find another use for this hook though. The inode_getsecctx hook we made for Labeled NFS was already merged because it was needed for providing "persistent" label support for sysfs (meaning that it persisted inode eviction from memory). The problem is that we have no real way to ask in the NFS code if this is an LSM that can be used with Labeled NFS. In the xattr code we have the new ismaclabel hook we add which allows us to verify the xattr used as belonging to a label based LSM however we need an xattr from userspace for that. The reason this is required is that the server will need to fill out its capability mask to indicate it supports security labeling. In addition the client also needs to know if its running a security label based LSM because it will need to mask out the label fattr bit from its getattr calls if it doesn't support it. We can override this in SELinux by giving it a context mount but if we don't then it will need to know whether or not to be pulling security labels back. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>> I'm not sure what the proposed hook would be for except to identify it >> as concerned with nfs. Perhaps the hook could return the names of >> attributes that it wants nfs to provide. >> > > I'm not quite sure what you're proposing? I'm sure someone would find > another use for this hook though. The inode_getsecctx hook we made for > Labeled NFS was already merged because it was needed for providing > "persistent" label support for sysfs (meaning that it persisted inode > eviction from memory). The problem is that we have no real way to ask in > the NFS code if this is an LSM that can be used with Labeled NFS. In the > xattr code we have the new ismaclabel hook we add which allows us to > verify the xattr used as belonging to a label based LSM however we need > an xattr from userspace for that. The reason this is required is that > the server will need to fill out its capability mask to indicate it > supports security labeling. In addition the client also needs to know if > its running a security label based LSM because it will need to mask out > the label fattr bit from its getattr calls if it doesn't support it. We > can override this in SELinux by giving it a context mount but if we > don't then it will need to know whether or not to be pulling security > labels back. > I think the point I'm trying to make is that we need to define the interface which if you implement it you are supported. For label import/export we have inode_{get,set,notify}secctx. For checking for xattr suitibility we have the new ismaclabel lsm call. Now the final thing we need to do is a call to determine if the lsm is suitable for Labeled NFS export meaning that it agrees to the semantics. Is inode{get,set,notify}_secctx and ismaclabel sufficient? I'm tempted to say we can make a call to inode_getsecctx and if it failes with EOPNOTSUPP we say we don't support it but then we need an initial file to call that on. This is why I'd rather have a LSM call that we can make that gives us a yes/no answer. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>> I'm not sure what the proposed hook would be for except to identify it >> as concerned with nfs. Perhaps the hook could return the names of >> attributes that it wants nfs to provide. >> > > I'm not quite sure what you're proposing? I'm sure someone would find > another use for this hook though. The inode_getsecctx hook we made for > Labeled NFS was already merged because it was needed for providing > "persistent" label support for sysfs (meaning that it persisted inode > eviction from memory). The problem is that we have no real way to ask in > the NFS code if this is an LSM that can be used with Labeled NFS. In the > xattr code we have the new ismaclabel hook we add which allows us to > verify the xattr used as belonging to a label based LSM however we need > an xattr from userspace for that. The reason this is required is that > the server will need to fill out its capability mask to indicate it > supports security labeling. In addition the client also needs to know if > its running a security label based LSM because it will need to mask out > the label fattr bit from its getattr calls if it doesn't support it. We > can override this in SELinux by giving it a context mount but if we > don't then it will need to know whether or not to be pulling security > labels back. > [Resending because I sent it from the wrong identity.] I think the point I'm trying to make is that we need to define the interface which if you implement it you are supported. For label import/export we have inode_{get,set,notify}secctx. For checking for xattr suitibility we have the new ismaclabel lsm call. Now the final thing we need to do is a call to determine if the lsm is suitable for Labeled NFS export meaning that it agrees to the semantics. Is inode{get,set,notify}_secctx and ismaclabel sufficient? I'm tempted to say we can make a call to inode_getsecctx and if it failes with EOPNOTSUPP we say we don't support it but then we need an initial file to call that on. This is why I'd rather have a LSM call that we can make that gives us a yes/no answer. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/support/include/nfs/export.h b/support/include/nfs/export.h index 1547a87..b8e2fb0 100644 --- a/support/include/nfs/export.h +++ b/support/include/nfs/export.h @@ -17,7 +17,8 @@ #define NFSEXP_ALLSQUASH 0x0008 #define NFSEXP_ASYNC 0x0010 #define NFSEXP_GATHERED_WRITES 0x0020 -/* 40, 80, 100 unused */ +#define NFSEXP_SECURITY_LABEL 0x0040 /* Support MAC attribute */ +/* 80, 100 unused */ #define NFSEXP_NOHIDE 0x0200 #define NFSEXP_NOSUBTREECHECK 0x0400 #define NFSEXP_NOAUTHNLM 0x0800 diff --git a/support/nfs/exports.c b/support/nfs/exports.c index a93941c..8965c8d 100644 --- a/support/nfs/exports.c +++ b/support/nfs/exports.c @@ -239,6 +239,8 @@ putexportent(struct exportent *ep) fprintf(fp, "%ssync,", (ep->e_flags & NFSEXP_ASYNC)? "a" : ""); fprintf(fp, "%swdelay,", (ep->e_flags & NFSEXP_GATHERED_WRITES)? "" : "no_"); + fprintf(fp, "%ssecurity_label,", (ep->e_flags & NFSEXP_SECURITY_LABEL)? + "" : "no"); fprintf(fp, "%shide,", (ep->e_flags & NFSEXP_NOHIDE)? "no" : ""); fprintf(fp, "%scrossmnt,", (ep->e_flags & NFSEXP_CROSSMOUNT)? @@ -531,6 +533,10 @@ parseopts(char *cp, struct exportent *ep, int warn, int *had_subtree_opt_ptr) setflags(NFSEXP_GATHERED_WRITES, active, ep); else if (!strcmp(opt, "no_wdelay")) clearflags(NFSEXP_GATHERED_WRITES, active, ep); + else if (strcmp(opt, "security_label") == 0) + ep->e_flags |= NFSEXP_SECURITY_LABEL; + else if (strcmp(opt, "nosecurity_label") == 0) + ep->e_flags &= ~NFSEXP_SECURITY_LABEL; else if (strcmp(opt, "root_squash") == 0) setflags(NFSEXP_ROOTSQUASH, active, ep); else if (!strcmp(opt, "no_root_squash")) diff --git a/utils/exportfs/exportfs.c b/utils/exportfs/exportfs.c index b78957f..6434825 100644 --- a/utils/exportfs/exportfs.c +++ b/utils/exportfs/exportfs.c @@ -531,6 +531,8 @@ dump(int verbose) c = dumpopt(c, "async"); if (ep->e_flags & NFSEXP_GATHERED_WRITES) c = dumpopt(c, "wdelay"); + if (ep->e_flags & NFSEXP_SECURITY_LABEL) + c = dumpopt(c, "security_label"); if (ep->e_flags & NFSEXP_NOHIDE) c = dumpopt(c, "nohide"); if (ep->e_flags & NFSEXP_CROSSMOUNT)