[RFC] Add color translation support to mcstransd

[RFC] Add color translation support to mcstransd

[Eamon Walsh]

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.


#
# Color translation table for SELinux
#
# The color mechanism supports separate foreground/background color pairs for
# each component of the context (user, role, type, level, and category).
# Shell-style wildcards are supported in user, role, and type patterns.
#
# Colors are specified as hexadecimal RGB values.  Each line must contain
# two colors separated by whitespace: a foreground (text) color and
# background (area) color.
#
# It is not generally necessary to define colors for all five components of
# the context.  The color mechanism will borrow colors from other components
# as necessary.  For example if no user, role, or type statements are present,
# the matching engine will use the level color for all four components.
#

# Example non-MLS color configuration
#  Display sysadm/system in black-on-red
role sysadm_r = 000000 ff0000
role system_r = 000000 ff0000

#  Display staff in black-on-yellow
role staff_r = 000000 ffff00

#  Display everything else in white-on-green
role * = ffffff 00ff00


# Example MLS color configuration
level s0 = ffff00 00ff00
level s1 = ff0000 ffff00
level s2 = ffff00 ff0000
level s15 = 0000ff ff0000

category c0 = ffffff 0000ff
category c1 = ffffff 00ff00
category c0.c1 = ffffff 00ffff
category c0.c255 = 0000ff ff0000





-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Add color translation support to mcstransd

[Joe Nall]

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

>
>
>
> #
> # Color translation table for SELinux
> #
> # The color mechanism supports separate foreground/background color  
> pairs for
> # each component of the context (user, role, type, level, and  
> category).
> # Shell-style wildcards are supported in user, role, and type  
> patterns.
> #
> # Colors are specified as hexadecimal RGB values.  Each line must  
> contain
> # two colors separated by whitespace: a foreground (text) color and
> # background (area) color.
> #
> # It is not generally necessary to define colors for all five  
> components of
> # the context.  The color mechanism will borrow colors from other  
> components
> # as necessary.  For example if no user, role, or type statements  
> are present,
> # the matching engine will use the level color for all four  
> components.
> #
>
> # Example non-MLS color configuration
> #  Display sysadm/system in black-on-red
> role sysadm_r = 000000 ff0000
> role system_r = 000000 ff0000
>
> #  Display staff in black-on-yellow
> role staff_r = 000000 ffff00
>
> #  Display everything else in white-on-green
> role * = ffffff 00ff00
>
>
> # Example MLS color configuration
> level s0 = ffff00 00ff00
> level s1 = ff0000 ffff00
> level s2 = ffff00 ff0000
> level s15 = 0000ff ff0000
>
> category c0 = ffffff 0000ff
> category c1 = ffffff 00ff00
> category c0.c1 = ffffff 00ffff
> category c0.c255 = 0000ff ff0000
>
>
>
>
>
> -- 
> Eamon Walsh <ewalsh@tycho.nsa.gov>
> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Add color translation support to mcstransd

[Eamon Walsh]

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@tycho.nsa.gov>
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Add color translation support to mcstransd

[Xavier Toth]

On Mon, Nov 24, 2008 at 1:25 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> 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@tycho.nsa.gov>
> National Security Agency
>
>

Sorry to be pedantic but is there a reference implementation or will
the mcstrans developer (Joe) have to develop it?

Ted

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Add color translation support to mcstransd

[Eamon Walsh]

Xavier Toth wrote:
> On Mon, Nov 24, 2008 at 1:25 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> 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@tycho.nsa.gov>
>> 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@tycho.nsa.gov>
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Add color translation support to mcstransd

[Eamon Walsh]

Eamon Walsh wrote:
> 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

A screen shot of a sample application that uses the color translations
can be seen at:
http://people.freedesktop.org/~ewalsh/mcscolor_screenshot.png


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Add color translation support to mcstransd

[Russell Coker]

On Saturday 06 December 2008 12:12, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> A screen shot of a sample application that uses the color translations
> can be seen at:
> http://people.freedesktop.org/~ewalsh/mcscolor_screenshot.png

That's interesting, the yellow/green colour scheme is a little difficult to 
read though.

Are there any plans for making sure that it's accessible?  I expect that even 
if the default configuration has no colour combinations that are bad for 
colour-blind people, the first thing that would happen is for people to 
immediately start adding them if there is no clear documentation about what 
not to do.

Also what about blind people?  Can this extra data be displayed in such a way 
that braille and speech-synthesis programs access it?

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Add color translation support to mcstransd

[Eamon Walsh]

Russell Coker wrote:
> On Saturday 06 December 2008 12:12, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>   
>> A screen shot of a sample application that uses the color translations
>> can be seen at:
>> http://people.freedesktop.org/~ewalsh/mcscolor_screenshot.png
>>     
>
> That's interesting, the yellow/green colour scheme is a little difficult to 
> read though.
>
> Are there any plans for making sure that it's accessible?  I expect that even 
> if the default configuration has no colour combinations that are bad for 
> colour-blind people, the first thing that would happen is for people to 
> immediately start adding them if there is no clear documentation about what 
> not to do.
>   

Choosing appropriate color combinations is the responsibility of the
people making the color policy.


> Also what about blind people?  Can this extra data be displayed in such a way 
> that braille and speech-synthesis programs access it?
>   

This would be the responsibility of the accessibility engine in the
application, for example by inserting some status notification when the
text color changes.

I don't think this is a real issue though, because if a speech synthesis
or braille reader is outputting the security context text in the first
place, the user will know the classification.

-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Add color translation support to mcstransd

[Eamon Walsh]

[-- Attachment #1: Type: text/plain, Size: 269 bytes --]

Xavier Toth wrote:
>
> Sorry to be pedantic but is there a reference implementation or will
> the mcstrans developer (Joe) have to develop it?
>
> Ted
>   

Also here is a preliminary libselinux patch.


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


[-- Attachment #2: setrans_color.patch --]
[-- Type: text/x-patch, Size: 4161 bytes --]

diff --git a/libselinux/include/selinux/selinux.h b/libselinux/include/selinux/selinux.h
index 3bfc0c8..aa0e328 100644
--- a/libselinux/include/selinux/selinux.h
+++ b/libselinux/include/selinux/selinux.h
@@ -504,6 +504,15 @@ extern int selinux_trans_to_raw_context(security_context_t trans,
 extern int selinux_raw_to_trans_context(security_context_t raw,
 					security_context_t * transp);
 
+/* Perform context translation between security contexts
+   and display colors.  Returns a space-separated list of ten
+   ten hex RGB triples prefixed by hash marks, e.g. "#ff0000".
+   Caller must free the resulting string via free.
+   Returns -1 upon an error or 0 otherwise.
+   If passed NULL, sets the returned string to NULL and returns 0. */
+extern int selinux_raw_context_to_color(security_context_t raw,
+					char **color_str);
+
 /* Get the SELinux username and level to use for a given Linux username. 
    These values may then be passed into the get_ordered_context_list*
    and get_default_context* functions to obtain a context for the user.
diff --git a/libselinux/src/selinux_internal.h b/libselinux/src/selinux_internal.h
index eaf1767..0eeca71 100644
--- a/libselinux/src/selinux_internal.h
+++ b/libselinux/src/selinux_internal.h
@@ -77,6 +77,7 @@ hidden_proto(selinux_getenforcemode);
 hidden_proto(selinux_getpolicytype);
 hidden_proto(selinux_raw_to_trans_context);
 hidden_proto(selinux_trans_to_raw_context);
+    hidden_proto(selinux_raw_context_to_color);
 hidden_proto(security_get_initial_context);
 hidden_proto(security_get_initial_context_raw);
 
diff --git a/libselinux/src/setrans_client.c b/libselinux/src/setrans_client.c
index a02f407..922f95c 100644
--- a/libselinux/src/setrans_client.c
+++ b/libselinux/src/setrans_client.c
@@ -30,6 +30,8 @@ static __thread security_context_t prev_t2r_trans = NULL;
 static __thread security_context_t prev_t2r_raw = NULL;
 static __thread security_context_t prev_r2t_trans = NULL;
 static __thread security_context_t prev_r2t_raw = NULL;
+static __thread char *prev_r2c_trans = NULL;
+static __thread security_context_t prev_r2c_raw = NULL;
 
 /*
  * setransd_open
@@ -212,12 +214,38 @@ static int trans_to_raw_context(char *trans, char **rawp)
 	return ret;
 }
 
+static int raw_context_to_color(char *raw, char **colors)
+{
+	int ret;
+	int32_t ret_val;
+	int fd;
+
+	fd = setransd_open();
+	if (fd < 0)
+		return fd;
+
+	ret = send_request(fd, RAW_CONTEXT_TO_COLOR, raw, NULL);
+	if (ret)
+		goto out;
+
+	ret = receive_response(fd, RAW_CONTEXT_TO_COLOR, colors, &ret_val);
+	if (ret)
+		goto out;
+
+	ret = ret_val;
+out:
+	close(fd);
+	return ret;
+}
+
 hidden void fini_context_translations(void)
 {
 	free(prev_r2t_trans);
 	free(prev_r2t_raw);
 	free(prev_t2r_trans);
 	free(prev_t2r_raw);
+	free(prev_r2c_trans);
+	free(prev_r2c_raw);
 }
 
 hidden int init_context_translations(void)
@@ -303,6 +331,39 @@ int selinux_raw_to_trans_context(security_context_t raw,
 }
 
 hidden_def(selinux_raw_to_trans_context)
+
+int selinux_raw_context_to_color(security_context_t raw, char **transp)
+{
+	if (!raw) {
+		*transp = NULL;
+		return 0;
+	}
+
+	if (prev_r2c_raw && strcmp(prev_r2c_raw, raw) == 0) {
+		*transp = strdup(prev_r2c_trans);
+	} else {
+		free(prev_r2c_raw);
+		prev_r2c_raw = NULL;
+		free(prev_r2c_trans);
+		prev_r2c_trans = NULL;
+		if (raw_context_to_color(raw, transp))
+			*transp = strdup(raw);
+		if (*transp) {
+			prev_r2c_raw = strdup(raw);
+			if (!prev_r2c_raw)
+				goto out;
+			prev_r2c_trans = strdup(*transp);
+			if (!prev_r2c_trans) {
+				free(prev_r2c_raw);
+				prev_r2c_raw = NULL;
+			}
+		}
+	}
+      out:
+	return *transp ? 0 : -1;
+}
+
+hidden_def(selinux_raw_context_to_color)
 #else /*DISABLE_SETRANS*/
 
 hidden void fini_context_translations(void)
diff --git a/libselinux/src/setrans_internal.h b/libselinux/src/setrans_internal.h
index 4e04b54..f6e25b1 100644
--- a/libselinux/src/setrans_internal.h
+++ b/libselinux/src/setrans_internal.h
@@ -4,6 +4,7 @@
 
 #define RAW_TO_TRANS_CONTEXT		2
 #define TRANS_TO_RAW_CONTEXT		3
+#define RAW_CONTEXT_TO_COLOR		4
 #define MAX_DATA_BUF			8192
 
 extern int init_context_translations(void);

Re: [RFC] Add color translation support to mcstransd

[Xavier Toth]

On Fri, Nov 21, 2008 at 9:59 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> 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.
>
>
> #
> # Color translation table for SELinux
> #
> # The color mechanism supports separate foreground/background color pairs for
> # each component of the context (user, role, type, level, and category).
> # Shell-style wildcards are supported in user, role, and type patterns.
> #
> # Colors are specified as hexadecimal RGB values.  Each line must contain
> # two colors separated by whitespace: a foreground (text) color and
> # background (area) color.
> #
> # It is not generally necessary to define colors for all five components of
> # the context.  The color mechanism will borrow colors from other components
> # as necessary.  For example if no user, role, or type statements are present,
> # the matching engine will use the level color for all four components.
> #
>
> # Example non-MLS color configuration
> #  Display sysadm/system in black-on-red
> role sysadm_r = 000000 ff0000
> role system_r = 000000 ff0000
>
> #  Display staff in black-on-yellow
> role staff_r = 000000 ffff00
>
> #  Display everything else in white-on-green
> role * = ffffff 00ff00
>
>
> # Example MLS color configuration
> level s0 = ffff00 00ff00
> level s1 = ff0000 ffff00
> level s2 = ffff00 ff0000
> level s15 = 0000ff ff0000
>
> category c0 = ffffff 0000ff
> category c1 = ffffff 00ff00
> category c0.c1 = ffffff 00ffff
> category c0.c255 = 0000ff ff0000
>
>
>
>
>
> --
> Eamon Walsh <ewalsh@tycho.nsa.gov>
> National Security Agency
>
>

Where does mcstrans look for secolor.conf? I can use names (red,
yellow, etc..) for colors instead of hex values, right?

Ted

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Add color translation support to mcstransd

[Eamon Walsh]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

Xavier Toth wrote:
> Where does mcstrans look for secolor.conf? I can use names (red,
> yellow, etc..) for colors instead of hex values, right?
>
> Ted
>
>   

I pushed two changes to the color-ewalsh branch addressing these issues,
please pull.

/etc/selinux/$POLICYTYPE/secolor.conf  is the location.

You can define names for colors using a new "color" rule in the conf
file.  Hex values are now specified with a leading hash mark to
distinguish them from symbolic names.

The "level" and "category" rules were dropped because, as alluded to in
another thread, SELinux does not expose knowledge of the MLS field to
the end user.  The only call available in the SELinux API is a dominance
check, hence I had to combine those two rules into a single "range" rule.

New example conf file attached.


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


[-- Attachment #2: secolor.conf --]
[-- Type: text/plain, Size: 1322 bytes --]

#
# Color translation table for SELinux
#
# The color mechanism supports separate foreground/background color pairs for
# each component of the context (user, role, type, and range).
# Shell-style wildcards are supported in user, role, and type patterns.
#
# Colors are specified as hexadecimal RGB values.  Each line must contain
# two colors separated by whitespace: a foreground (text) color and
# background (area) color.
#
# It is not generally necessary to define colors for all five components of
# the context.  The color mechanism will borrow colors from other components
# as necessary.  For example if no user, role, or type statements are present,
# the matching engine will use the range color for all four components.
#

# Color definitions
color red   = #ff0000
color green = #00ff00
color blue  = #0000ff
color yellow = #ffff00
color black = #000000
color white = #ffffff

# Example non-MLS color configuration
#  Display sysadm/system in black-on-red
#role sysadm_r = black red
#role system_r = black red

#  Display staff in black-on-yellow
#role staff_r = black yellow

#  Display everything else in yellow-on-green
#role * = yellow green


# Example MLS color configuration
range s0:c0.c255 = yellow green
range s1:c0.c255 = red yellow
range s2:c0.c255 = yellow red
range s15:c0.c255 = #ffff00 #ff00ff

Re: [RFC] Add color translation support to mcstransd

[Xavier Toth]

On Thu, Dec 18, 2008 at 2:14 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> Xavier Toth wrote:
>> Where does mcstrans look for secolor.conf? I can use names (red,
>> yellow, etc..) for colors instead of hex values, right?
>>
>> Ted
>>
>>
>
> I pushed two changes to the color-ewalsh branch addressing these issues,
> please pull.
>
> /etc/selinux/$POLICYTYPE/secolor.conf  is the location.
>
> You can define names for colors using a new "color" rule in the conf
> file.  Hex values are now specified with a leading hash mark to
> distinguish them from symbolic names.
>
> The "level" and "category" rules were dropped because, as alluded to in
> another thread, SELinux does not expose knowledge of the MLS field to
> the end user.  The only call available in the SELinux API is a dominance
> check, hence I had to combine those two rules into a single "range" rule.
>
> New example conf file attached.
>
>
> --
> Eamon Walsh <ewalsh@tycho.nsa.gov>
> National Security Agency
>
>
> #
> # Color translation table for SELinux
> #
> # The color mechanism supports separate foreground/background color pairs for
> # each component of the context (user, role, type, and range).
> # Shell-style wildcards are supported in user, role, and type patterns.
> #
> # Colors are specified as hexadecimal RGB values.  Each line must contain
> # two colors separated by whitespace: a foreground (text) color and
> # background (area) color.
> #
> # It is not generally necessary to define colors for all five components of
> # the context.  The color mechanism will borrow colors from other components
> # as necessary.  For example if no user, role, or type statements are present,
> # the matching engine will use the range color for all four components.
> #
>
> # Color definitions
> color red   = #ff0000
> color green = #00ff00
> color blue  = #0000ff
> color yellow = #ffff00
> color black = #000000
> color white = #ffffff
>
> # Example non-MLS color configuration
> #  Display sysadm/system in black-on-red
> #role sysadm_r = black red
> #role system_r = black red
>
> #  Display staff in black-on-yellow
> #role staff_r = black yellow
>
> #  Display everything else in yellow-on-green
> #role * = yellow green
>
>
> # Example MLS color configuration
> range s0:c0.c255 = yellow green
> range s1:c0.c255 = red yellow
> range s2:c0.c255 = yellow red
> range s15:c0.c255 = #ffff00 #ff00ff
>
>

If I miss configure secolor.conf mcstransd fails to start instead I'd
prefer that it log the error and continue.

Ted

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Add color translation support to mcstransd

[Xavier Toth]

On Thu, Dec 11, 2008 at 3:35 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> Xavier Toth wrote:
>>
>> Sorry to be pedantic but is there a reference implementation or will
>> the mcstrans developer (Joe) have to develop it?
>>
>> Ted
>>
>
> Also here is a preliminary libselinux patch.
>
>
> --
> Eamon Walsh <ewalsh@tycho.nsa.gov>
> National Security Agency
>
>

This patch could be upstreamed now because even if the installed
mcstrand doesn't support color a call to selinux_raw_context_to_color
will simply retrun an error, right?

Ted

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Add color translation support to mcstransd

[Eamon Walsh]

Xavier Toth wrote:
> On Thu, Dec 11, 2008 at 3:35 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>   
>> Xavier Toth wrote:
>>     
>>> Sorry to be pedantic but is there a reference implementation or will
>>> the mcstrans developer (Joe) have to develop it?
>>>
>>> Ted
>>>
>>>       
>> Also here is a preliminary libselinux patch.
>>
>>
>> --
>> Eamon Walsh <ewalsh@tycho.nsa.gov>
>> National Security Agency
>>
>>
>>     
>
> This patch could be upstreamed now because even if the installed
> mcstrand doesn't support color a call to selinux_raw_context_to_color
> will simply retrun an error, right?
>
> Ted
>
>   

Yes, the function will return error in that case.

Without objection, I will go ahead and upstream the
selinux_raw_context_to_color() and selinux_colors_path() functions. 
Patch below.

Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
---

 libselinux/include/selinux/selinux.h |    9 +++++
 libselinux/src/file_path_suffixes.h  |    1 +
 libselinux/src/selinux_config.c      |   10 +++++-
 libselinux/src/selinux_internal.h    |    1 +
 libselinux/src/setrans_client.c      |   61 ++++++++++++++++++++++++++++++++++
 libselinux/src/setrans_internal.h    |    1 +
 6 files changed, 82 insertions(+), 1 deletions(-)


diff --git a/libselinux/include/selinux/selinux.h b/libselinux/include/selinux/selinux.h
index 3bfc0c8..fab083e 100644
--- a/libselinux/include/selinux/selinux.h
+++ b/libselinux/include/selinux/selinux.h
@@ -467,6 +467,7 @@ extern const char *selinux_customizable_types_path(void);
 extern const char *selinux_users_path(void);
 extern const char *selinux_usersconf_path(void);
 extern const char *selinux_translations_path(void);
+extern const char *selinux_colors_path(void);
 extern const char *selinux_netfilter_context_path(void);
 extern const char *selinux_path(void);
 
@@ -504,6 +505,14 @@ extern int selinux_trans_to_raw_context(security_context_t trans,
 extern int selinux_raw_to_trans_context(security_context_t raw,
 					security_context_t * transp);
 
+/* Perform context translation between security contexts
+   and display colors.  Returns a space-separated list of ten
+   ten hex RGB triples prefixed by hash marks, e.g. "#ff0000".
+   Caller must free the resulting string via free.
+   Returns -1 upon an error or 0 otherwise. */
+extern int selinux_raw_context_to_color(security_context_t raw,
+					char **color_str);
+
 /* Get the SELinux username and level to use for a given Linux username. 
    These values may then be passed into the get_ordered_context_list*
    and get_default_context* functions to obtain a context for the user.
diff --git a/libselinux/src/file_path_suffixes.h b/libselinux/src/file_path_suffixes.h
index bea5c40..8d207c9 100644
--- a/libselinux/src/file_path_suffixes.h
+++ b/libselinux/src/file_path_suffixes.h
@@ -19,3 +19,4 @@ S_(BINPOLICY, "/policy/policy")
     S_(FILE_CONTEXTS_HOMEDIR, "/contexts/files/file_contexts.homedirs")
     S_(FILE_CONTEXTS_LOCAL, "/contexts/files/file_contexts.local")
     S_(X_CONTEXTS, "/contexts/x_contexts")
+    S_(COLORS, "/secolor.conf")
diff --git a/libselinux/src/selinux_config.c b/libselinux/src/selinux_config.c
index 7dbbb47..dec5426 100644
--- a/libselinux/src/selinux_config.c
+++ b/libselinux/src/selinux_config.c
@@ -39,7 +39,8 @@
 #define FILE_CONTEXTS_LOCAL 17
 #define SECURETTY_TYPES   18
 #define X_CONTEXTS        19
-#define NEL               20
+#define COLORS            20
+#define NEL               21
 
 /* New layout is relative to SELINUXDIR/policytype. */
 static char *file_paths[NEL];
@@ -356,6 +357,13 @@ const char *selinux_translations_path()
 
 hidden_def(selinux_translations_path)
 
+const char *selinux_colors_path()
+{
+	return get_path(COLORS);
+}
+
+hidden_def(selinux_colors_path)
+
 const char *selinux_netfilter_context_path()
 {
 	return get_path(NETFILTER_CONTEXTS);
diff --git a/libselinux/src/selinux_internal.h b/libselinux/src/selinux_internal.h
index eaf1767..0eeca71 100644
--- a/libselinux/src/selinux_internal.h
+++ b/libselinux/src/selinux_internal.h
@@ -77,6 +77,7 @@ hidden_proto(selinux_getenforcemode);
 hidden_proto(selinux_getpolicytype);
 hidden_proto(selinux_raw_to_trans_context);
 hidden_proto(selinux_trans_to_raw_context);
+    hidden_proto(selinux_raw_context_to_color);
 hidden_proto(security_get_initial_context);
 hidden_proto(security_get_initial_context_raw);
 
diff --git a/libselinux/src/setrans_client.c b/libselinux/src/setrans_client.c
index a02f407..500225e 100644
--- a/libselinux/src/setrans_client.c
+++ b/libselinux/src/setrans_client.c
@@ -30,6 +30,8 @@ static __thread security_context_t prev_t2r_trans = NULL;
 static __thread security_context_t prev_t2r_raw = NULL;
 static __thread security_context_t prev_r2t_trans = NULL;
 static __thread security_context_t prev_r2t_raw = NULL;
+static __thread char *prev_r2c_trans = NULL;
+static __thread security_context_t prev_r2c_raw = NULL;
 
 /*
  * setransd_open
@@ -212,12 +214,38 @@ static int trans_to_raw_context(char *trans, char **rawp)
 	return ret;
 }
 
+static int raw_context_to_color(char *raw, char **colors)
+{
+	int ret;
+	int32_t ret_val;
+	int fd;
+
+	fd = setransd_open();
+	if (fd < 0)
+		return fd;
+
+	ret = send_request(fd, RAW_CONTEXT_TO_COLOR, raw, NULL);
+	if (ret)
+		goto out;
+
+	ret = receive_response(fd, RAW_CONTEXT_TO_COLOR, colors, &ret_val);
+	if (ret)
+		goto out;
+
+	ret = ret_val;
+out:
+	close(fd);
+	return ret;
+}
+
 hidden void fini_context_translations(void)
 {
 	free(prev_r2t_trans);
 	free(prev_r2t_raw);
 	free(prev_t2r_trans);
 	free(prev_t2r_raw);
+	free(prev_r2c_trans);
+	free(prev_r2c_raw);
 }
 
 hidden int init_context_translations(void)
@@ -303,6 +331,39 @@ int selinux_raw_to_trans_context(security_context_t raw,
 }
 
 hidden_def(selinux_raw_to_trans_context)
+
+int selinux_raw_context_to_color(security_context_t raw, char **transp)
+{
+	if (!raw) {
+		*transp = NULL;
+		return -1;
+	}
+
+	if (prev_r2c_raw && strcmp(prev_r2c_raw, raw) == 0) {
+		*transp = strdup(prev_r2c_trans);
+	} else {
+		free(prev_r2c_raw);
+		prev_r2c_raw = NULL;
+		free(prev_r2c_trans);
+		prev_r2c_trans = NULL;
+		if (raw_context_to_color(raw, transp))
+			return -1;
+		if (*transp) {
+			prev_r2c_raw = strdup(raw);
+			if (!prev_r2c_raw)
+				goto out;
+			prev_r2c_trans = strdup(*transp);
+			if (!prev_r2c_trans) {
+				free(prev_r2c_raw);
+				prev_r2c_raw = NULL;
+			}
+		}
+	}
+      out:
+	return *transp ? 0 : -1;
+}
+
+hidden_def(selinux_raw_context_to_color)
 #else /*DISABLE_SETRANS*/
 
 hidden void fini_context_translations(void)
diff --git a/libselinux/src/setrans_internal.h b/libselinux/src/setrans_internal.h
index 4e04b54..f6e25b1 100644
--- a/libselinux/src/setrans_internal.h
+++ b/libselinux/src/setrans_internal.h
@@ -4,6 +4,7 @@
 
 #define RAW_TO_TRANS_CONTEXT		2
 #define TRANS_TO_RAW_CONTEXT		3
+#define RAW_CONTEXT_TO_COLOR		4
 #define MAX_DATA_BUF			8192
 
 extern int init_context_translations(void);



-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Add color translation support to mcstransd

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eamon Walsh wrote:
> Xavier Toth wrote:
>> On Thu, Dec 11, 2008 at 3:35 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>>   
>>> Xavier Toth wrote:
>>>     
>>>> Sorry to be pedantic but is there a reference implementation or will
>>>> the mcstrans developer (Joe) have to develop it?
>>>>
>>>> Ted
>>>>
>>>>       
>>> Also here is a preliminary libselinux patch.
>>>
>>>
>>> --
>>> Eamon Walsh <ewalsh@tycho.nsa.gov>
>>> National Security Agency
>>>
>>>
>>>     
>> This patch could be upstreamed now because even if the installed
>> mcstrand doesn't support color a call to selinux_raw_context_to_color
>> will simply retrun an error, right?
>>
>> Ted
>>
>>   
> 
> Yes, the function will return error in that case.
> 
> Without objection, I will go ahead and upstream the
> selinux_raw_context_to_color() and selinux_colors_path() functions. 
> Patch below.
> 
> Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
> ---
> 
>  libselinux/include/selinux/selinux.h |    9 +++++
>  libselinux/src/file_path_suffixes.h  |    1 +
>  libselinux/src/selinux_config.c      |   10 +++++-
>  libselinux/src/selinux_internal.h    |    1 +
>  libselinux/src/setrans_client.c      |   61 ++++++++++++++++++++++++++++++++++
>  libselinux/src/setrans_internal.h    |    1 +
>  6 files changed, 82 insertions(+), 1 deletions(-)
> 
> 
> diff --git a/libselinux/include/selinux/selinux.h b/libselinux/include/selinux/selinux.h
> index 3bfc0c8..fab083e 100644
> --- a/libselinux/include/selinux/selinux.h
> +++ b/libselinux/include/selinux/selinux.h
> @@ -467,6 +467,7 @@ extern const char *selinux_customizable_types_path(void);
>  extern const char *selinux_users_path(void);
>  extern const char *selinux_usersconf_path(void);
>  extern const char *selinux_translations_path(void);
> +extern const char *selinux_colors_path(void);
>  extern const char *selinux_netfilter_context_path(void);
>  extern const char *selinux_path(void);
>  
> @@ -504,6 +505,14 @@ extern int selinux_trans_to_raw_context(security_context_t trans,
>  extern int selinux_raw_to_trans_context(security_context_t raw,
>  					security_context_t * transp);
>  
> +/* Perform context translation between security contexts
> +   and display colors.  Returns a space-separated list of ten
> +   ten hex RGB triples prefixed by hash marks, e.g. "#ff0000".
> +   Caller must free the resulting string via free.
> +   Returns -1 upon an error or 0 otherwise. */
> +extern int selinux_raw_context_to_color(security_context_t raw,
> +					char **color_str);
> +
>  /* Get the SELinux username and level to use for a given Linux username. 
>     These values may then be passed into the get_ordered_context_list*
>     and get_default_context* functions to obtain a context for the user.
> diff --git a/libselinux/src/file_path_suffixes.h b/libselinux/src/file_path_suffixes.h
> index bea5c40..8d207c9 100644
> --- a/libselinux/src/file_path_suffixes.h
> +++ b/libselinux/src/file_path_suffixes.h
> @@ -19,3 +19,4 @@ S_(BINPOLICY, "/policy/policy")
>      S_(FILE_CONTEXTS_HOMEDIR, "/contexts/files/file_contexts.homedirs")
>      S_(FILE_CONTEXTS_LOCAL, "/contexts/files/file_contexts.local")
>      S_(X_CONTEXTS, "/contexts/x_contexts")
> +    S_(COLORS, "/secolor.conf")
> diff --git a/libselinux/src/selinux_config.c b/libselinux/src/selinux_config.c
> index 7dbbb47..dec5426 100644
> --- a/libselinux/src/selinux_config.c
> +++ b/libselinux/src/selinux_config.c
> @@ -39,7 +39,8 @@
>  #define FILE_CONTEXTS_LOCAL 17
>  #define SECURETTY_TYPES   18
>  #define X_CONTEXTS        19
> -#define NEL               20
> +#define COLORS            20
> +#define NEL               21
>  
>  /* New layout is relative to SELINUXDIR/policytype. */
>  static char *file_paths[NEL];
> @@ -356,6 +357,13 @@ const char *selinux_translations_path()
>  
>  hidden_def(selinux_translations_path)
>  
> +const char *selinux_colors_path()
> +{
> +	return get_path(COLORS);
> +}
> +
> +hidden_def(selinux_colors_path)
> +
>  const char *selinux_netfilter_context_path()
>  {
>  	return get_path(NETFILTER_CONTEXTS);
> diff --git a/libselinux/src/selinux_internal.h b/libselinux/src/selinux_internal.h
> index eaf1767..0eeca71 100644
> --- a/libselinux/src/selinux_internal.h
> +++ b/libselinux/src/selinux_internal.h
> @@ -77,6 +77,7 @@ hidden_proto(selinux_getenforcemode);
>  hidden_proto(selinux_getpolicytype);
>  hidden_proto(selinux_raw_to_trans_context);
>  hidden_proto(selinux_trans_to_raw_context);
> +    hidden_proto(selinux_raw_context_to_color);
>  hidden_proto(security_get_initial_context);
>  hidden_proto(security_get_initial_context_raw);
>  
> diff --git a/libselinux/src/setrans_client.c b/libselinux/src/setrans_client.c
> index a02f407..500225e 100644
> --- a/libselinux/src/setrans_client.c
> +++ b/libselinux/src/setrans_client.c
> @@ -30,6 +30,8 @@ static __thread security_context_t prev_t2r_trans = NULL;
>  static __thread security_context_t prev_t2r_raw = NULL;
>  static __thread security_context_t prev_r2t_trans = NULL;
>  static __thread security_context_t prev_r2t_raw = NULL;
> +static __thread char *prev_r2c_trans = NULL;
> +static __thread security_context_t prev_r2c_raw = NULL;
>  
>  /*
>   * setransd_open
> @@ -212,12 +214,38 @@ static int trans_to_raw_context(char *trans, char **rawp)
>  	return ret;
>  }
>  
> +static int raw_context_to_color(char *raw, char **colors)
> +{
> +	int ret;
> +	int32_t ret_val;
> +	int fd;
> +
> +	fd = setransd_open();
> +	if (fd < 0)
> +		return fd;
> +
> +	ret = send_request(fd, RAW_CONTEXT_TO_COLOR, raw, NULL);
> +	if (ret)
> +		goto out;
> +
> +	ret = receive_response(fd, RAW_CONTEXT_TO_COLOR, colors, &ret_val);
> +	if (ret)
> +		goto out;
> +
> +	ret = ret_val;
> +out:
> +	close(fd);
> +	return ret;
> +}
> +
>  hidden void fini_context_translations(void)
>  {
>  	free(prev_r2t_trans);
>  	free(prev_r2t_raw);
>  	free(prev_t2r_trans);
>  	free(prev_t2r_raw);
> +	free(prev_r2c_trans);
> +	free(prev_r2c_raw);
>  }
>  
>  hidden int init_context_translations(void)
> @@ -303,6 +331,39 @@ int selinux_raw_to_trans_context(security_context_t raw,
>  }
>  
>  hidden_def(selinux_raw_to_trans_context)
> +
> +int selinux_raw_context_to_color(security_context_t raw, char **transp)
> +{
> +	if (!raw) {
> +		*transp = NULL;
> +		return -1;
> +	}
> +
> +	if (prev_r2c_raw && strcmp(prev_r2c_raw, raw) == 0) {
> +		*transp = strdup(prev_r2c_trans);
> +	} else {
> +		free(prev_r2c_raw);
> +		prev_r2c_raw = NULL;
> +		free(prev_r2c_trans);
> +		prev_r2c_trans = NULL;
> +		if (raw_context_to_color(raw, transp))
> +			return -1;
> +		if (*transp) {
> +			prev_r2c_raw = strdup(raw);
> +			if (!prev_r2c_raw)
> +				goto out;
> +			prev_r2c_trans = strdup(*transp);
> +			if (!prev_r2c_trans) {
> +				free(prev_r2c_raw);
> +				prev_r2c_raw = NULL;
> +			}
> +		}
> +	}
> +      out:
> +	return *transp ? 0 : -1;
> +}
> +
> +hidden_def(selinux_raw_context_to_color)
>  #else /*DISABLE_SETRANS*/
>  
>  hidden void fini_context_translations(void)
> diff --git a/libselinux/src/setrans_internal.h b/libselinux/src/setrans_internal.h
> index 4e04b54..f6e25b1 100644
> --- a/libselinux/src/setrans_internal.h
> +++ b/libselinux/src/setrans_internal.h
> @@ -4,6 +4,7 @@
>  
>  #define RAW_TO_TRANS_CONTEXT		2
>  #define TRANS_TO_RAW_CONTEXT		3
> +#define RAW_CONTEXT_TO_COLOR		4
>  #define MAX_DATA_BUF			8192
>  
>  extern int init_context_translations(void);
> 
> 
> 
Can you bump the version number?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklijnIACgkQrlYvE4MpobNQBgCeLNJTnIEt+s5QMxLMYEKj4/OR
9V8An0FkSTcm//sGlBgWl5FnssRxCxAz
=r1ky
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.