GNOME Bugzilla – Bug 356753
Label support for SELinux
Last modified: 2020-11-07 12:37:09 UTC
Display of SELinux Context info needs to be displayed as part of the frame. I am currently working on this, I hope to make this generic as possible so that the core support code can be included in the standard metacity source with the SELnux options available as a compile time option.
(In reply to comment #0) > Display of SELinux Context info needs to be displayed as part of the frame. What is SELinux Context info? Why does it need to be displayed as part of the frame?
A little background info on SELinux and addition all Window Manager requirements. Every process in SELinux has a security context. This context indicates what resources a process can access, this covers everything from syscalls to files - all data transfers as well as data at rest. All data is labeled to indicate access restrictions, processes also have labels - this provides a mechanism to control data access. Running a windowed graphics system brings up many issues which we are currently working on. I have been tasked with the window manager portion since I have experience in development of window managers - I worked on some of the earliest X11 Window Managers. Since each process has a label; this implies that each window has to also have a label, this is an absolute requirement for an SELinux system to provide a windowed user interface. Since Metacity is a simple and clean Window Manager that is the default GNOME wm I have proposed to use it. It would be nice to implement the graphics support as a simple hook in the Metacity, the SELinux code would be a compile time configuration item, only SELinux systems would utilize this since SELinux specific syscalls are used. I would anticipate that the SELinux file would be < 100 lines. I would like to add a configuration option so that libselinux is linked the compile is done. I beleive the support would involve a few lines in theme.c perhaps theme-parser.c. Additions to configure would allow for the optional addition of the selinux support and link to libselinux.
(In reply to comment #2) > Since each process has a label; this implies that each window has to also have > a label, this is an absolute requirement for an SELinux system to provide a > windowed user interface. I don't understand the why the implication follows nor how it helps the user. I'm not saying it doesn't, just that I don't understand what these labels are suppose to mean or what users would do with them. > It would be nice to implement the graphics support as a simple hook in the > Metacity, the SELinux code would be a compile time configuration item, only > SELinux systems would utilize this since SELinux specific syscalls are used. I > would anticipate that the SELinux file would be < 100 lines. I would like to > add a configuration option so that libselinux is linked the compile is done. > > I believe the support would involve a few lines in theme.c perhaps > theme-parser.c. Additions to configure would allow for the optional addition > of the selinux support and link to libselinux. Sounds like it's probably reasonable. I'd really like to get Havoc's and Thomas's comments, though, as I don't know squat about security or SELinux (other than the fact that I have to deal with the weirdness of the latter nowadays to get bugzilla work done on box.gnome.org and that I tend to disable it on my personal machine to avoid such stuff), and don't have any familiarity with theme.c or theme-parser.c.
Created attachment 73118 [details] Demo version of Metacity with Labels This is a screen shot of a Fedora Core 6 box running MLS policy with a tweaked Metacity window manager. The level of the application is displayed above the theme items in the frame.
I have attached a screen shot of a Red Hat Fedora system with SELinux using a customized MLS Policy. This may clarify the purpose of the security labels. I bounced this off Havoc a couple of weeks ago to see if anyone had started on this - he told me that he was not aware of anyone who had started on this. As you can see in the image, each window has a label (this system is not really classified, it's just a demonstration!) The label on the window tells the user what the classification of each window is - more exactly the highest. This enables the simultaneous display of information with different security levels. I guess I was not clear on the need for this - it is absolutly required to have these labels on a system that can display classified data as illustrated in the example image. The need for a window manager that supports this is absolute and not optional. Since we are at the bleeding edge of this in the Linux world there is not yet support for X on a SELinux system. Since everyone in our community will have a requirement for this I was hoping to submit the source so we will not have to maintain our own branch. BTW: The Window Manager that is on our old operating system is mwm, or rather a version that was modified (by HP, I believe) to support labels (and other more obscure MLS extensions) You can find out more about MLS and Trusted Operating systems at http://en.wikipedia.org/wiki/Trusted_operating_system
we definitely need some better UI for this. Maybe add something to the window menu instead? I'd be surprised if very many users would want those always displayed all the time.
Ah, yes, a picture is worth a thousand words. Looks like something the extremely security conscious would want, so it looks useful to include. I think certain niche usages (classified government work or whatever) would actually want labels as in-your-face as this (at least that is the kind of impression I got while doing internships at a couple of the national labs, even though I didn't personally do anything classified or even interact with anyone who did (to the best of my knowledge, anyway)). As Rob points out though, most Gnome users aren't part of such a niche; e.g. I use Fedora which has selinux by default, but I definitely wouldn't want those in-your-face labels. What's the suggestion for such users?
I have an idea for a more general use of this feature: indicating when a window is running as another user. Wouldn't it be nice if you could see that your gnome-terminal was currently executing as root? Or that your gdmsetup window would actually be able to save its changes? When I was thinking about this last week I was picturing something more like Firefox does with the URL bar with SSL sites. It turns the location bar background yellow and italicizes the font. Maybe you could apply some sort of effect on the border rendering to indicate a security context? Turn the window border yellow and add some text in bold that says "Highly Classified Window", or "running as root!".
(In reply to comment #8) > I have an idea for a more general use of this feature: indicating when a window > is running as another user. Wouldn't it be nice if you could see that your This is exactly what I was hoping for, I would like to add the basic graphic functionality as a generic feature - someone might come up with a cool use for this unrelated to what I am up to. The SElinux requirements, or more exactly, the government requirements would be a compile-time option - which would fill the label area with the classification info. "real world" systems could use the area for something else. Actually there are some nice possibilties for this labeling for the private sector. Red Hat has a policy called MCS which is geared for business and will be part of REL 5 (due this year). In this policy you have the option of labeling files "COMPANY PROPRIETARY", etc. It would be a cool feature for users of this policy to have windows look like they do now, but say you bring up a proprietary document in Open Office then the banner "COMPANY PROPRIETARY" will pop up. This is very useful because the user might be prevented from doing certain things, like printing the document out, etc - so rather than just mysteriously not working there would be a flag saying "there are some things you may not be allow to do" More info on this: http://www.coker.com.au/selinux/talks/auug-2005/auug2005-paper.html
Great. I'm thinking this could be part of <frame_style_set>. How many different security clearances are there? I was thinking of something like <frame_style_set name="normal"> <frame focus="yes" state="shaded" style="focused_shaded_classified" clearance="classified"/> <frame focus="yes" state="normal" resize="both" style="focused_classified" clearance="classified"/> <frame focus="yes" state="maximized" style="focused_maximized_classified" clearance="classified"/> <frame focus="yes" state="maximized_and_shaded" style="focused_maximized_classified" clearance="classified"/> <frame focus="no" state="normal" resize="both" style="normal_classified" clearance="classified"/> <frame focus="no" state="shaded" style="normal_shaded_classified" clearance="classified"/> <frame focus="no" state="maximized" style="normal_maximized_classified" clearance="classified"/> <frame focus="no" state="maximized_and_shaded" style="normal_maximized_classified" clearance="classified"/> <frame focus="yes" state="shaded" style="focused_shaded" clearance="normal"/> <frame focus="yes" state="normal" resize="both" style="focused" clearance="normal"/> <frame focus="yes" state="maximized" style="focused_maximized" clearance="normal"/> <frame focus="yes" state="maximized_and_shaded" style="focused_maximized" clearance="normal"/> <frame focus="no" state="normal" resize="both" style="normal" clearance="normal"/> <frame focus="no" state="shaded" style="normal_shaded" clearance="normal"/> <frame focus="no" state="maximized" style="normal_maximized" clearance="normal"/> <frame focus="no" state="maximized_and_shaded" style="normal_maximized" clearance="normal"/> </frame_style_set>
There can actually be 100's of classification strings, the coloring is just based on part of the string so there would be 5 or six colors. The strings provided by SELinux, part of the mix is a Trusted X Server which provides the security info to the Window Manager. The window manager should not care for the most part what the string actually is, there is usually a config file that tells what color a given label should be. BTW one of the important things about these labels has to do with basic functions, cut and paste is more complex in the world of classified systems...you can cut from a SECRET window into a TOP SECRET window, but not the other way around...a Trusted X Server has the added requirement to control this - as you can imagine, things like properties, atoms, etc can get pretty complex... ANYWAY, what I think the core window manager needs is a way to provide the label in the frame and provide an API for the text and color to be set - on an SELinux compile a function that knows the SELinux stuff would call this API. If any non-seliux user wanted to put something there, they would provide a function that called the same API to put the hostname, outside temperature or Zen thought of the day (or whatever) in the label.
Making this themeable seems a bit pointless since department of defense / CIA / NSA super-locked-down workstations probably aren't a preferred place to experiment with 1337 themes. Also, theme authors simply aren't going to spend time on this, since none of them will use it. I think an important goal would be to keep the metacity changes as small and simple as possible, this codepath will not get tested much and would need to be reliable. If it can be done, a clean solution might be: - there is a _NET_SECURITY_LABEL property containing the name - there is a _NET_SECURITY_COLOR property containing the color - the secure X server is configured such that only the correct properties can be set - metacity just displays whatever is in the property, in a theme-independent way (just always draws a colored bar with the label) I don't know how the trust stuff works, though.
Created attachment 73897 [details] Demo of theme tweak for frame - part of possible solution I have attached a patch to theme.c from 2.16 (this is the one used by Fedora Core 6) that adds space for a label at the top of a frame. I have strived to make my footprint on theme.c as minimal as possible. I think with the addition of the label_height variable, a couple of api entries (set_label_height() is included to demonstrate this) would do the trick. The theme code does not care what's in the label, it just makes space for it. At this point my biggest question is whether I am doing this in a good way, or if it seems brain-damaged. With the theme.c that results from this patch I could add in code that renders the label. The next thing I have to come up is a way to add the hook to the code that creates the label, I would like to be able to use a callback type mechanism, that way I could put the hook in the theme.c (I think that's where it would end up) and all of the SELinux shtuff would be isolated from the mainline. My dream solution would be to have the SELinux label feature to be a compile time option of the release version. With such a small footprint in theme.c I think this can be done without too much fuss. If you want to try this out - patch theme.c, change label_height from zero to some value e.g. 20 - You'll see a blank area above the theme stuff...this is where the SELinux Goop will go. I think I'm on the right track...hope you all agree! - Chris -
Created attachment 85482 [details] [review] labeled windows when running metacity on XACE xserver branch Here is a patch I generated to label windows when running the XACE branch of the xserver. It does nothing if the _SELINUX_CLIENT_CONTEXT property doesn't exist and if the SELinux context doesn't contain a level. The basics are here I don't claim to be a X programmer so hopefully more experienced people will have better ideas on how to render the label.
I can't parse comment 14; I don't have any idea what lots of different things mean and have no understanding of the general issue/idea. I don't know what XACE is, what the _SELINUX_CLIENT_CONTEXT property is supposed to be or what the "SELinux context" is, and I don't know how to determine if the patch was meant as a fix to this bug or it just happened to be a patch dropped in a bug that looked similar (we get those occasionally...) A brief idea of what the patch is about, what it is trying to achieve, how that relates to the things that Chris and Havoc mentioned in this bug, etc., would be really helpful. Also, please use the -p flag to diff when creating patches. Some basic comments on minor issues in the patch, mostly formatting: This looks really weird (huge spacing on the second line): - mini_icon, icon); + button_states, mini_icon, icon, Alignment here is off: + MetaTheme *theme, + char *label) ("label" and "theme" should line up). There were several other similar examples. This change does nothing but introduce breaks to style consistency: - for (i = 0; i < MAX_BUTTONS_PER_CORNER; i++) - { + for (i = 0; i < MAX_BUTTONS_PER_CORNER; i++) { What is "MLS level"? What in the world is "er" in "get_label_color_by_er"? Why the divide by two in: - fgeom->title_rect.y = layout->title_border.top; + if (label) { + fgeom->title_rect.y = layout->title_border.top + label_height / 2; + } Why three separate calls to meta_verbose instead of one: + meta_verbose ("fgeom->top_height %d\n", fgeom->top_height); + meta_verbose ("layout->title_border.top %d\n", layout->title_border.top); + meta_verbose ("layout->title_border.bottom %d\n", layout->title_border.bottom); Also, there were other places where you had much more than 3 calls. The arguments don't line up here: + meta_ui_set_frame_label (window->screen->ui, + window->frame->xwindow, + window->label); "window" should line up on each line.
Elijah, aiui the basic idea is that a window displaying "confidential info level 2" would say "confidential window level 2" on it and maybe be color coded. Certain government agencies like to do this.
> I have an idea for a more general use of this feature: indicating when a window > is running as another user. Wouldn't it be nice if you could see that your > gnome-terminal was currently executing as root? Or that your gdmsetup window > would actually be able to save its changes? My gnome-terminals usually contain multiple tabs, some of which run sshs logged into various systems, some of them running as root, some of them as myself. Do I get a rainbow on top ?
Some more comments on the patch: - it introduces new source files without copyright notice. - I'd use a simple loop to skip the 4 ':'s rather than multiple strtok_r - the way in which labeltocolor.c maps random substrings to fixed colors is a) not understandable - what are the patterns, why are they chosen ? b) not maintainable c) not very failsafe - what if the string matches multiple patterns ? I'd propose a table-driven approach for this, and then it is also easy to read that table from some external configuration instead of hardcoding it
Created attachment 113042 [details] [review] Patch to display SELinux security contexts Based on Ted Toth's patch. Uses the GConf key "/apps/metacity/general/show_security_label" to control whether the security label is displayed or not. Only displays the raw selinux context, it does not use different colors. Adds the selinux context to the same Pango layout as the title, which is less obtrusive and doesn't conflict with theme support.
Just an initial thought: /apps/metacity/general/show_security_label : is this really what we want to be doing? Do people not want to turn on all the security stuff at once? (I'm thinking there's probably a security section somewhere like the accessibility section, which we already refer to.)
(In reply to comment #18) > Some more comments on the patch: > > - it introduces new source files without copyright notice. > > - I'd use a simple loop to skip the 4 ':'s rather than multiple strtok_r > > - the way in which labeltocolor.c maps random substrings to fixed > colors is > a) not understandable - what are the patterns, why are they chosen ? > b) not maintainable > c) not very failsafe - what if the string matches multiple patterns ? > I'd propose a table-driven approach for this, and then it is also > easy to read that table from some external configuration instead of > hardcoding it > Sorry I wasn't on the cc list so I didn't know that there was further discussion about labeling. Regarding you first and third points in my latest patch I removed the color code in favor of call to a shared library if it exists which supplies an interface for retrieving the color based on the context. Your second point can be taken care of with the use of context parsing API in libselinux which I wasn't aware of at the time I originally developed this patch. I will try and work with James to get a merged patch together.
(In reply to comment #19) > Created an attachment (id=113042) [edit] > Patch to display SELinux security contexts > > Based on Ted Toth's patch. > > Uses the GConf key "/apps/metacity/general/show_security_label" to > control whether the security label is displayed or not. > > Only displays the raw selinux context, it does not use different colors. > > Adds the selinux context to the same Pango layout as the title, > which is less obtrusive and doesn't conflict with theme support. > I think there needs to be a key, like a format, that allows for the configuration of what parts of the context are displayed. I'm not so hot on the idea of having a key to turn them off.
Some possibly better, possibly crazy ideas here about how not to use GConf: - Is the secrecy level a property of an entire X server at once? Then it should be a property on the root window and not a GConf key, especially since that means you'll be able to check it from programs that don't know about GConf. - Is the secrecy level a property of particular windows (you can have some windows with one security label and others with another?) Then it should be an X property on those windows. See previous entry for rationale. - Is the secrecy level something that can be figured out if we know what program put up the window? (For example, suppose they run gedit in secret mode with pid 12345 and there's something we can give the number 12345 to and get back that the mode is secret.) Then we can use _NET_WM_PID to find out the pid and figure it out from there.
Here are some comments based on a quick pass over the patch (I haven't even built it): + case META_PREF_SHOW_SECURITY_LABEL: + return "SHOW SECURITY LABEL"; All the other cases seem to have _ instead of spaces. Might be better to keep it that way. + if (value->type != META_PROP_VALUE_INVALID) + { + set_window_label (window, value->v.str); + } + else + { + set_window_label (window, NULL); + } Looking around a bit, it seems that metacity coding style doesn't use {} around single statements in ifs or elses. - frame->layout = gtk_widget_create_pango_layout (widget, frame->title); + frame->layout = gtk_widget_create_pango_layout (widget, NULL); + + char *title; + if (meta_prefs_get_show_security_label () && frame->label) + title = g_strdup_printf (_("%s \n%s"), + frame->label, frame->title); + else + title = g_strdup (frame->title); + pango_layout_set_text(frame->layout, title, strlen(title)); + g_free (title); Would be slightly nicer to figure out the text before and create the layout with the right text, as it was before. + if (meta_prefs_get_show_security_label () && frame->label) + title = g_strdup_printf (_("%s \n%s"), + frame->label, frame->title); + else + title = g_strdup (frame->title); It doesn't make too much sense to me to translate that little template. What does make sense and is still missing is to replace the raw selinux contexts with translated strings that make some sense to the user. But maybe that can wait until later.
> Some possibly better, possibly crazy ideas here about how not to use GConf: Thomas, it is a "security context", not a "secrecy level". The security context is a property of the process. So, it is not something global to the xserver, but rather a property of each individual toplevel window - which is how it is exposed by the XSelinux extension (the X server make the selinux context of the client available as a property on the toplevel window). What we need in gconf is a setting to tell metacity whether to do anything with these security contexts or not
(In reply to comment #23) > Some possibly better, possibly crazy ideas here about how not to use GConf: > > - Is the secrecy level a property of an entire X server at once? Then it > should be a property on the root window and not a GConf key, especially since > that means you'll be able to check it from programs that don't know about > GConf. > > - Is the secrecy level a property of particular windows (you can have some > windows with one security label and others with another?) Then it should be an > X property on those windows. See previous entry for rationale. > > - Is the secrecy level something that can be figured out if we know what > program put up the window? (For example, suppose they run gedit in secret mode > with pid 12345 and there's something we can give the number 12345 to and get > back that the mode is secret.) Then we can use _NET_WM_PID to find out the pid > and figure it out from there. > Yes each window has its' own context. The _SELINUX_CLIENT_CONTEXT atom contains a windows context. There is a XCB SELinux interface that can be used to retrieve the context of a window. I think that with the next release of XCB the SELinux interface will be available current it only exists in the git tree.
(In reply to comment #22) > (In reply to comment #19) > > Created an attachment (id=113042) [edit] > > Patch to display SELinux security contexts > > > > Based on Ted Toth's patch. > > > > Uses the GConf key "/apps/metacity/general/show_security_label" to > > control whether the security label is displayed or not. > > > > Only displays the raw selinux context, it does not use different colors. > > > > Adds the selinux context to the same Pango layout as the title, > > which is less obtrusive and doesn't conflict with theme support. > > > > I think there needs to be a key, like a format, that allows for the > configuration of what parts of the context are displayed. I'm not so hot on the > idea of having a key to turn them off. > If the key is in /etc/gconf/gconf.xml.mandatory, then a normal user cannot change it. Most likely the options desired would be: off, show the whole context, and show only the MLS portion.
(In reply to comment #25) > What we need in gconf is a setting to tell metacity whether to do anything with > these security contexts or not Okay. There are situations where we'd want to ignore them, then? And there are no plans for, say, a /desktop/gnome/security GConf directory? (I imagine the extension prevents a client spoofing the property for itself, but we probably want to check whether the extension is present and not honour the property if it isn't, so that people aren't confused by untrue labels.)
(In reply to comment #28) > (In reply to comment #25) > > What we need in gconf is a setting to tell metacity whether to do anything with > > these security contexts or not > > Okay. There are situations where we'd want to ignore them, then? And there Some people won't want labeled windows at all. It is not likely to change much once set. > are no plans for, say, a /desktop/gnome/security GConf directory? > No plans for that at this time. > (I imagine the extension prevents a client spoofing the property for itself, > but we probably want to check whether the extension is present and not honour > the property if it isn't, so that people aren't confused by untrue labels.) > The client can't write the property, and if it is not present, then there is no label, so I don't believe that there can be an untrue label.
(In reply to comment #29) > (In reply to comment #28) > > (I imagine the extension prevents a client spoofing the property for itself, > > but we probably want to check whether the extension is present and not honour > > the property if it isn't, so that people aren't confused by untrue labels.) > > > The client can't write the property, and if it is not present, then there is no > label, so I don't believe that there can be an untrue label. One of us is misunderstanding here; probably it's me. With this extension, a client can't set the _SELINUX_CLIENT_CONTEXT property on its own windows. But without this extension, on an ordinary X server, this is just another property, and I don't see why a client can't set the property in that case. In such a case, if Metacity is always sensitive to the property, would it attempt to display the label?
(In reply to comment #30) > (In reply to comment #29) > > (In reply to comment #28) > > > (I imagine the extension prevents a client spoofing the property for itself, > > > but we probably want to check whether the extension is present and not honour > > > the property if it isn't, so that people aren't confused by untrue labels.) > > > > > The client can't write the property, and if it is not present, then there is no > > label, so I don't believe that there can be an untrue label. > > One of us is misunderstanding here; probably it's me. With this extension, a > client can't set the _SELINUX_CLIENT_CONTEXT property on its own windows. But > without this extension, on an ordinary X server, this is just another property, > and I don't see why a client can't set the property in that case. In such a > case, if Metacity is always sensitive to the property, would it attempt to > display the label? > In previous discussions with Eamon (the X SELinux extension author) he indicated that it was preferable to use the XCB interface to get the window context instead of using this property. So once this interface is available it should be used and then concerns about _SELINUX_CLIENT_CONTEXT will be moot.
Until then, metacity could just check for the availability of the XSelinux extension and not display labels if the extension is not present/disabled.
Several things to consider: 1) the context can be wider than the window so it would be good if it were scrollable or if the full context could be viewed in a mouseover/tooltip. 2) when I mentioned that I'd like a way to specify a format I was thinking that I could specify a which parts of context I'd like displayed. Context is made up of the SELinux user, role, type and level so maybe like a C format string we could use %u for the user, %r for role, %t for type and %l for level. As an example I might want the role and the level displayed. 3) there is an issue with the fact that once the window is labeled that label (as someone else mentioned) may not reflect the context of the window contents if for instance I had done a 'newrole' to change my context. Unfortunately I don't have a solution for this scenario.
(In reply to comment #33) > 3) there is an issue with the fact that once the window is labeled that label > (as someone else mentioned) may not reflect the context of the window contents > if for instance I had done a 'newrole' to change my context. Unfortunately I > don't have a solution for this scenario. I think you want a graphical replacement for newrole in the desktop environment where the graphical newrole program spawns a process in the desired context before creating the window so that the window is properly labeled in the first place. Then you just disallow use of newrole -l within a gnome-terminal by excluding the devpts types from securetty_types.
(In reply to comment #31) There are two properties that the SELinux extension sets on all windows. The _SELINUX_CONTEXT property contains the context of the window itself. The _SELINUX_CLIENT_CONTEXT property contains the context of the process that owns the window. There are also SELinux extension protocol requests that can be used to get the same information: GetWindowContext and GetClientContext. However, the XCB binding has not been released yet (a release is pending within weeks according to XCB sources). Modern versions of Xlib depend on XCB, so it should be safe to assume it's presence, although I'm not familiar with GNOME's support for older Xlibs. Given the hold-up waiting for the XCB release, using the properties in the patch should be fine. In the long term I would like to stop setting the properties from the X server, but this can be phased in later. (In reply to comment #34) This is getting a little off-topic, but yes, there is a problem with responding to context changes in terminal windows. Always creating new windows is the best solution. Let's assume for now that window contexts remain fixed. If this becomes impossible then the SELinux extension can grow an event that notifies the window manager of a context change. Changing the context of a window mid-stream would be pretty difficult, however. I hope it doesn't come to that.
Review of attachment 113042 [details] [review]: (This was reviewed in the comments.) You mentioned a new version of this patch; was this ever created?
If there is interest I could probably produce a current version of my patch which James based his on.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use metacity and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.