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@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.
