Xavier Toth wrote: > On Mon, Nov 24, 2008 at 1:25 PM, Eamon Walsh <ewalsh@xxxxxxxxxxxxx> wrote: > >> Joe Nall wrote: >> >>> On Nov 21, 2008, at 9:59 PM, Eamon Walsh wrote: >>> >>> >>> >>>> The proposal is to add 2 new functions to mcstransd: >>>> RAW_CONTEXT_TO_COLOR and TRANS_CONTEXT_TO_COLOR, and to add a new >>>> configuration file "secolor.conf", similar to setrans.conf, which >>>> contains mappings from security context components into colors. >>>> >>>> The purpose of this facility is to service SELinux-aware graphical >>>> applications which display security contexts. Standard color schemes >>>> are often associated with security levels or categories. The proposed >>>> color facility allows color policy to be expressed in the same >>>> manner as >>>> the existing human-readable translation strings in setrans.conf. >>>> Example uses include security labels in a window manager, >>>> headers/footers in documents or printouts, or downgrade dialogs in >>>> selection managers. >>>> >>>> The proposed color lookup operation supports up to 10 colors: a >>>> foreground/background pair for each component of the security context >>>> (user, role, type, level, and category). If all five components are >>>> not >>>> specified in the configuration file, the matching engine will copy >>>> from >>>> other components to fill out the 10 colors according to fallback >>>> rules. >>>> For example, if colors are only specified for levels, the other four >>>> color pairs will be set to the value specified for the level. This >>>> allows maximum flexibility while supporting the common case of only >>>> displaying a single foreground/background or even just a background >>>> color. >>>> >>>> Below is a sample secolor.conf file. Comments appreciated. >>>> >>>> >>> So you get 10 values back every time? >>> >>> What happens when there is no matching mapping? >>> >>> How are the fallback rules specified? >>> >>> This is way spiffier than what I was looking to do. I like it. >>> >>> joe >>> >>> >>> >> Yes, under this proposal there are 10 colors returned for every lookup. >> The return value is a big string containing hex values separated by >> whitespace, such as: >> 000000 ffff00 000000 ffff00 000000 ffff00 000000 ffff00 000000 >> ffff00 >> I experimented with returning binary 32-bit integers on the wire, but >> all the mcstransd logic is set up to handle strings. The client-side >> code (in libselinux) could parse the values. >> >> The fallback rules for borrowing colors from other parts of the context >> are hardcoded to the following: >> >> user falls back to: role, type, level, category, black/white >> role falls back to: user, type, level, category, black/white >> type falls back to: user, role, level, category, black/white >> level falls back to: category, user, role, type, black/white >> category falls back to: level, user, role type, black/white >> >> For example if there is no match found for the "role" component, then >> the role color will be set to the user color, if there was a match for >> the user in the secolor.conf file. If not, then the role color will be >> set to the type color, if there was a match for the type. And so on. >> If any one component matches then all five components will fall back to >> it, and the rules are set up so that TE/RBAC colors borrow from other >> TE/RBAC components first and MLS colors borrow from the other MLS >> components first. The idea is that a simple application that is only >> capable of displaying one color (e.g. metacity) could always use the >> first one in the message (the "user" one). >> >> If there is no match for any part of the context then black-on-white is >> returned. The secolor.conf file should have a wildcard rule for one of >> the components to prevent this. >> >> It was pointed out by Jim that some color policies might define separate >> colors for combinations of level/category the same way "SystemHigh" is >> defined as s15:c0.c255. This could be solved by a new rule that treats >> category and level together when matching. It seems like there are an >> infinite number of possibilities for color policy requirements. This >> proposed scheme is somewhat flexible in that more colors could be added >> to the message later. >> >> >> -- >> Eamon Walsh <ewalsh@xxxxxxxxxxxxx> >> National Security Agency >> >> >> > > Sorry to be pedantic but is there a reference implementation or will > the mcstrans developer (Joe) have to develop it? > I have placed the code into a git repository which can be checked out with: git-clone git://people.freedesktop.org/~ewalsh/mcstrans The "master" branch contains the code that was in the SRPM file that Joe posted to this list in June. If you have more recent changes send them my way and I will update the repo to include them. The "color-ewalsh" branch contains the color code for the proposal above. There have been some changes, namely: The format of the returned string is now hex digits with hash marks, e.g. "#000000 #ffffff #000000 #ffffff..." The separate "level" and "category" rules have been dropped and replaced by a single "range" rule. The SELinux interface does not expose the details of the MLS component of the security context. The only function offered is a "dominance" check implemented as a permission bit on the "context" security class (and even this doesn't currently work correctly, because it only accepts domains as the subject context, more on this in another post). Whether the details, which would include the ebitmaps for categories and level numbers, should be exposed is up for debate. Because of this only eight colors are now returned. -- Eamon Walsh <ewalsh@xxxxxxxxxxxxx> National Security Agency -- 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.
