Re: F20 System Wide Change: Enable SELinux Labeled NFS Support
On Fri, Jul 26, 2013 at 06:54:16AM -0400, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/26/2013 03:40 AM, Florian Weimer wrote: On 07/25/2013 08:55 PM, Daniel J Walsh wrote: Labels are applied based on the client rules. Which does bring up an interesting idea of what happens if the server initiates a relabel. Can we make sure that there's a good chance that the NFS exports reside under a tree that is not subject to relabeling? Otherwise, that operation would be rather destructive and even insecure. I don't think so. In the case of remote users directory this is likely but I don't see anyway we can get an server admin to put exported content under a directory path that is labeled correctly on both the client and server. Of course we can recommend this, or explain /etc/selinux/fixfiles_exclude_dirs which he can setup to prevent this. nod I think that it may not be immediately obvious to admins what all the caveats to using this are. Having good documentation of the implications of the Change and pointing to that in the Release Notes seems very important to inform admins of what to expect. Just for the technical aspect of the change, this seems like a great improvement :-) -Toshio pgpPq_zQeDJ7M.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Enable SELinux Labeled NFS Support
On 7/26/2013 6:55 AM, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/2013 06:45 PM, James Hogarth wrote: On 25 Jul 2013 19:55, Daniel J Walsh dwa...@redhat.com mailto:dwa...@redhat.com wrote: snip The only provisos/additions I could suggest on the above then is to make it clear in the release notes that server and client should be matching for any additional fcontext rules to eliminate any server/client relabel discrepancies. In addition rather than defaulting to the file_t context might I suggest using the current/standard nfs_t context for unknown labels (unless overridden by mount options of course)? I am not sure we can do this. Eric do you know of a way to do something like this? I don't believe this is possible with our current implementation. I'd need to look again. The caveat for this operating mode in the IETF specification we wrote is the the policies are homogenous in this environment. The server is not really label aware. Its mostly supposed to be simple attribute storage. In our case here it is aware however because we don't currently have any policy translation infrastructure it is supposed to be a homogenous environment. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Enable SELinux Labeled NFS Support
On 7/28/2013 1:40 AM, Dave Quigley wrote: On 7/26/2013 6:55 AM, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/2013 06:45 PM, James Hogarth wrote: On 25 Jul 2013 19:55, Daniel J Walsh dwa...@redhat.com mailto:dwa...@redhat.com wrote: snip The only provisos/additions I could suggest on the above then is to make it clear in the release notes that server and client should be matching for any additional fcontext rules to eliminate any server/client relabel discrepancies. In addition rather than defaulting to the file_t context might I suggest using the current/standard nfs_t context for unknown labels (unless overridden by mount options of course)? I am not sure we can do this. Eric do you know of a way to do something like this? I don't believe this is possible with our current implementation. I'd need to look again. The caveat for this operating mode in the IETF specification we wrote is the the policies are homogenous in this environment. The server is not really label aware. Its mostly supposed to be simple attribute storage. In our case here it is aware however because we don't currently have any policy translation infrastructure it is supposed to be a homogenous environment. Dave Also another tidbit of information. Currently the server has no idea what the security context of the process making the filesystem call to an NFS mount. The next phase of Labeled NFS is to work on implementing RPCSECGSSv3 which among other useful features allows us to assert the security context of the calling process from the client. So its not possible for the server to make truely informed decisions about NFS calls. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Enable SELinux Labeled NFS Support
On 07/25/2013 08:55 PM, Daniel J Walsh wrote: Labels are applied based on the client rules. Which does bring up an interesting idea of what happens if the server initiates a relabel. Can we make sure that there's a good chance that the NFS exports reside under a tree that is not subject to relabeling? Otherwise, that operation would be rather destructive and even insecure. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Enable SELinux Labeled NFS Support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/26/2013 03:40 AM, Florian Weimer wrote: On 07/25/2013 08:55 PM, Daniel J Walsh wrote: Labels are applied based on the client rules. Which does bring up an interesting idea of what happens if the server initiates a relabel. Can we make sure that there's a good chance that the NFS exports reside under a tree that is not subject to relabeling? Otherwise, that operation would be rather destructive and even insecure. I don't think so. In the case of remote users directory this is likely but I don't see anyway we can get an server admin to put exported content under a directory path that is labeled correctly on both the client and server. Of course we can recommend this, or explain /etc/selinux/fixfiles_exclude_dirs which he can setup to prevent this. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHyVVgACgkQrlYvE4MpobOrmgCeLl5nA8tjN/02iC7qUBNnecKO pEwAn2SqfutigDOcXXgr4YN0wogqu9CF =LERT -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Enable SELinux Labeled NFS Support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/2013 06:45 PM, James Hogarth wrote: On 25 Jul 2013 19:55, Daniel J Walsh dwa...@redhat.com mailto:dwa...@redhat.com wrote: snip The only provisos/additions I could suggest on the above then is to make it clear in the release notes that server and client should be matching for any additional fcontext rules to eliminate any server/client relabel discrepancies. In addition rather than defaulting to the file_t context might I suggest using the current/standard nfs_t context for unknown labels (unless overridden by mount options of course)? I am not sure we can do this. Eric do you know of a way to do something like this? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHyVYoACgkQrlYvE4MpobO7HwCePWO8Tf+TEgsirrDGbpgsdS+A Y+EAoLoubT9w+KZSGE+SpGMjeN5n+Kg/ =xdCE -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F20 System Wide Change: Enable SELinux Labeled NFS Support
= Proposed System Wide Change: Enable SELinux Labeled NFS Support = https://fedoraproject.org/wiki/Changes/LabeledNFS Change owner(s): Daniel Walsh dwa...@redhat.com, Steve Dickson ste...@redhat.com The Linux Kernel has grown support for passing SELinux labels between a client and server using NFS. == Detailed description == We have always needed to treat NFS mounts with a single label usually something like nfs_t. Or at best allow an administrator to override the default with a label using the mount --context option. With this change we have lots of different Labels supported on an NFS share. == Scope == Proposal owners: * Steve Dickson needs to make sure nfs-utils works properly. * Dan Walsh needs to make sure selinux-policy works properly in all use cases. Other developers: Kernel * Turn on Labeled NFS in the Fedora Kernel, Fix any policy issues that arise because of this. I believe this is mainly a testing issue, and that the functionality is complete. Release engineering: N/A (No changes for Release Engineering) Policies and guidelines: N/A (not affected) ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Enable SELinux Labeled NFS Support
On Thu, Jul 25, 2013 at 01:11:01PM +0200, Jaroslav Reznik wrote: = Proposed System Wide Change: Enable SELinux Labeled NFS Support = https://fedoraproject.org/wiki/Changes/LabeledNFS Change owner(s): Daniel Walsh dwa...@redhat.com, Steve Dickson ste...@redhat.com The Linux Kernel has grown support for passing SELinux labels between a client and server using NFS. == Detailed description == We have always needed to treat NFS mounts with a single label usually something like nfs_t. Or at best allow an administrator to override the default with a label using the mount --context option. With this change we have lots of different Labels supported on an NFS share. == Scope == Proposal owners: * Steve Dickson needs to make sure nfs-utils works properly. * Dan Walsh needs to make sure selinux-policy works properly in all use cases. Other developers: Kernel * Turn on Labeled NFS in the Fedora Kernel, Fix any policy issues that arise because of this. I believe this is mainly a testing issue, and that the functionality is complete. Release engineering: N/A (No changes for Release Engineering) Policies and guidelines: N/A (not affected) I think this feature needs to cover some app integration testing. For example, one of the core use cases for NFS/SELinux support is to enable sVirt to work for KVM guests with storage on NFS. So I think the feature should include testing to validate that it is working with sVirt, as a downstream user of the feature. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Enable SELinux Labeled NFS Support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/2013 07:17 AM, Daniel P. Berrange wrote: I think this feature needs to cover some app integration testing. For example, one of the core use cases for NFS/SELinux support is to enable sVirt to work for KVM guests with storage on NFS. So I think the feature should include testing to validate that it is working with sVirt, as a downstream user of the feature. Regards, Daniel -- Updated testing section on https://fedoraproject.org/wiki/Changes/LabeledNFS -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHxHpgACgkQrlYvE4MpobPVwACg4HRCvMW45ph9wjqUso2S0RXN uCUAoKM+ujY0mF72L7bf6rxMjFyNcjUz =qZR3 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Enable SELinux Labeled NFS Support
On Thu, Jul 25, 2013 at 08:48:24AM -0400, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/2013 07:17 AM, Daniel P. Berrange wrote: I think this feature needs to cover some app integration testing. For example, one of the core use cases for NFS/SELinux support is to enable sVirt to work for KVM guests with storage on NFS. So I think the feature should include testing to validate that it is working with sVirt, as a downstream user of the feature. Regards, Daniel -- Updated testing section on https://fedoraproject.org/wiki/Changes/LabeledNFS Feature looks good to me now. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Enable SELinux Labeled NFS Support
On 25 Jul 2013 14:36, Daniel P. Berrange berra...@redhat.com wrote: Updated testing section on https://fedoraproject.org/wiki/Changes/LabeledNFS Feature looks good to me now. A few bits that come to immediate mind: Are the labels applied following the semanage fcontext rules from server or client side.. Or can either do this? Does root squash have an impact on this? Does fedup initiate a full system relabel already and if it doesn't should it do so - and should automatic relabelling take place after the NFS mount target is reached if client context configuration has an impact? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Enable SELinux Labeled NFS Support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/2013 10:57 AM, James Hogarth wrote: On 25 Jul 2013 14:36, Daniel P. Berrange berra...@redhat.com mailto:berra...@redhat.com wrote: Updated testing section on https://fedoraproject.org/wiki/Changes/LabeledNFS Feature looks good to me now. A few bits that come to immediate mind: Are the labels applied following the semanage fcontext rules from server or client side.. Or can either do this? Labels are applied based on the client rules. Which does bring up an interesting idea of what happens if the server initiates a relabel. Theoretically the server should not even need to be enabled for the labeling to work. There could be a problem if the client tries to apply a label that the server does not understand. But for now we just require both sides to agree on labels. Does root squash have an impact on this? I hope not. I would figure if a process is allowed to write to mount point, it can assign labels to the mount point. Does fedup initiate a full system relabel already and if it doesn't should it do so No and No. - - and should automatic relabelling take place after the NFS mount target is reached if client context configuration has an impact? No, we only want the labels to be assigned when the user creates content or if the files on the remote side had lables. If a file did not have a label the kernel would assign it file_t. If the client runs a restorecon it would label the NFS share based on its path. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHxdLAACgkQrlYvE4MpobNJxACgp7Qx045ZWSZd4vGk+dUCy2Wi 7RIAoMm5obtk4rDPwTitas6kQHoTPkmF =OFZK -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Enable SELinux Labeled NFS Support
On 25 Jul 2013 19:55, Daniel J Walsh dwa...@redhat.com wrote: snip The only provisos/additions I could suggest on the above then is to make it clear in the release notes that server and client should be matching for any additional fcontext rules to eliminate any server/client relabel discrepancies. In addition rather than defaulting to the file_t context might I suggest using the current/standard nfs_t context for unknown labels (unless overridden by mount options of course)? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
