GNOME Bugzilla – Bug 529694
SELinux context setting support
Last modified: 2021-06-18 15:29:39 UTC
This is a modified patch adding ability to change SELinux context within Nautilus File Properties dialog. The original patch was written by James Antill, previous review request is available at https://bugzilla.redhat.com/show_bug.cgi?id=204030. By default, combobox with list of available contexts is shown. In Advanced Permissions mode, combo is replaced by entry for direct context string input, implementing context autocomplete. Both combo and entry are disabled when selinux is disabled in the system and controls are hidden when Nautilus is built without selinux support. Please review the patch and let me know your concerns. It would be great to have this feature in trunk before final 2.24 release. Some screenshots: http://fedorapeople.org/~tbzatek/Screenshot-selinux.png http://fedorapeople.org/~tbzatek/Screenshot-selinux2.png
Created attachment 109812 [details] [review] nautilus-2.22.2-selinux.diff
Created attachment 109813 [details] [review] glib-selinux-set-support.diff Required patch to glib/gio adding 'selinux::context' attribute set support
Grr, not fun to hide glib patches in nautilus bugs. Please commit the glib patch.
* gfileinfo.c: Support setting selinux attributes. Patch by Tomas Bzatek
Confirming. IIRC Thomas and I already discussed on IRC that the Nautilus part can not go in, due to the display name hack: selinux__hack_conv_type(scan->data); SELinux should provide means of generating a user-visible name for an internal context name, and should do all the translation handling.
As I understand it, this is setting the SELinux context of the file in the extended attrs, but not adjusting the policy, so that next time a relabel happens, the xattr will get overwritten back. Would it make more sense to show both: (i) the current xattr context of the file (ii) the context the file should have according to policy and highlight when they are different (matchpathcon, which it looks like the code is reading, but can't edit yet) Maybe only show (ii) when they're different? Should the UI allow the user to adjust the policy (e.g. to set policy so that /srv/www has httpd context)? Otherwise you're going to be constantly having to relabel by hand after an automatic relabel happens.
(In reply to comment #5) > IIRC Thomas and I already discussed on IRC that the Nautilus part can not go > in, due to the display name hack: > > selinux__hack_conv_type(scan->data); Setting patch as 'needs-work' for this reason, though I'm not sure this patch still applies cleanly to master. Tomas, will you do further work to upstream this beast? :)
(In reply to comment #6) > As I understand it, this is setting the SELinux context of the file in the > extended attrs, but not adjusting the policy, so that next time a relabel > happens, the xattr will get overwritten back. Yes, that's right. Not even sure how many users are actually using Nautilus to change SELinux context. I guess modifying the policy would require root permissions, that means involving PolicyKit, with preferred way through GIO (perhaps with help of gvfs). We should teach the libs beneath to use PolicyKit first. > Would it make more sense to show both: > (i) the current xattr context of the file > (ii) the context the file should have according to policy > and highlight when they are different (matchpathcon, which it looks like the > code is reading, but can't edit yet) > > Maybe only show (ii) when they're different? > > Should the UI allow the user to adjust the policy (e.g. to set policy so that > /srv/www has httpd context)? Otherwise you're going to be constantly having to > relabel by hand after an automatic relabel happens. It makes sense but I would do this as a step two, because of the concerns above. Perhaps we can show a warning to let user know what he's doing. (In reply to comment #7) > Setting patch as 'needs-work' for this reason, though I'm not sure this patch > still applies cleanly to master. With minor modifications, it still does. We continue to maintain it in Fedora git. > Tomas, will you do further work to upstream this beast? :) I plan to but not in near timeframe, my TODO list is way too long at the moment.
Modifying the policy really looks like a sysadmin or OS vendor type of operation. Do we really think that Nautilus is the right place for this?
An oldy but goody. The only thing nautilus should do would be to have the ability to alter the label (context) on a file. Probably just needs restrorecon capability, But modifying a piece of content to be https_sys_content_t would be as advanced as you would need. I don't see a need to add any priv ops to nautlus as far as modifying policy.
Created attachment 221387 [details] [review] latest version of the downstream patch FWIW, here's the latest version of the downstream patch (I don't think it applies to nautilus git anymore).
Review of attachment 221387 [details] [review]: [ Marking needs-work as it doesn't apply and is probably not what we really want ]
You said "need-work", but the tag is "need-info"... This would be a real improvement. At list, Nautilus should be able to display the security context.
No, the patch is needs-work. The bug itself is not NEEDINFO.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.