Context translation and MLS categories

Context translation and MLS categories

[Ivan Gyurdiev]

To integrate selinux with nautilus, I'd like to have a function which 
provides me with a list of translated (sensitivity, category) pairs, as 
setrans.conf specifies. Then I can present a list of those strings to 
the user.

The question is...where should this function be located, and what kind 
of API will it have?

Currently I have a raw context that is supplied by gnome-vfs. Clearly I 
need to break that down into fields. I want the user to configure the 
individual fields, not have a box to type in the context. This breakdown 
seems like it should be internal to selinux libraries. A good place to 
do it is in the sepol context record. However, currently libsepol is 
completely unaware of translations - all it can do is supply the raw mls 
range, or possibly expand the mls range into some other format - like a 
list of (sens, cat) pairs.

That still leaves translation to be done... but libselinux does not 
provide any API for doing translation at the level of an mls range, or 
even an individual (sensitivty, category) pair. It only allows 
translation at the context level. Why is translation done at the context 
level, and can I add additional APIs to translate at mls_range, or 
individual sensitivity/category level. How does this affect the MITRE 
translation library that I've been hearing about?



--
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: Context translation and MLS categories

[Stephen Smalley]

On Tue, 2006-02-28 at 00:37 -0500, Ivan Gyurdiev wrote:
> To integrate selinux with nautilus, I'd like to have a function which 
> provides me with a list of translated (sensitivity, category) pairs, as 
> setrans.conf specifies. Then I can present a list of those strings to 
> the user.
> 
> The question is...where should this function be located, and what kind 
> of API will it have?
> 
> Currently I have a raw context that is supplied by gnome-vfs. Clearly I 
> need to break that down into fields. I want the user to configure the 
> individual fields, not have a box to type in the context. This breakdown 
> seems like it should be internal to selinux libraries. A good place to 
> do it is in the sepol context record. However, currently libsepol is 
> completely unaware of translations - all it can do is supply the raw mls 
> range, or possibly expand the mls range into some other format - like a 
> list of (sens, cat) pairs.
> 
> That still leaves translation to be done... but libselinux does not 
> provide any API for doing translation at the level of an mls range, or 
> even an individual (sensitivty, category) pair. It only allows 
> translation at the context level. Why is translation done at the context 
> level, and can I add additional APIs to translate at mls_range, or 
> individual sensitivity/category level. How does this affect the MITRE 
> translation library that I've been hearing about?

Translation at the entire context level was just for maximal generality
(and consistent with the general goal of encapsulating the context as
much as possible), but in practice, only the MLS component is being
translated presently.  Exporting APIs from libsetrans for translation of
the range should be fine, IMHO.  Be careful to not misunderstand the
structure of a MLS range/level though, e.g. s0:c0,c1,c3,c7 has to be
interpreted as a whole, not as a list of pairs, for the full encoding
scheme used by the MITRE library, IIUC.  Joe Nall also recently asked
about extending libsetrans to support inverse bit encodings.

-- 
Stephen Smalley
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: Context translation and MLS categories

[Ivan Gyurdiev]

>>
>> That still leaves translation to be done... but libselinux does not 
>> provide any API for doing translation at the level of an mls range, or 
>> even an individual (sensitivty, category) pair. It only allows 
>> translation at the context level. Why is translation done at the context 
>> level, and can I add additional APIs to translate at mls_range, or 
>> individual sensitivity/category level. How does this affect the MITRE 
>> translation library that I've been hearing about?
>>     
>
> Translation at the entire context level was just for maximal generality
> (and consistent with the general goal of encapsulating the context as
> much as possible), but in practice, only the MLS component is being
> translated presently.  Exporting APIs from libsetrans
Should I be exporting APIs from libsetrans... or from libselinux using 
libsetrans?

>  for translation of
> the range should be fine, IMHO.  Be careful to not misunderstand the
> structure of a MLS range/level though, e.g. s0:c0,c1,c3,c7 has to be
> interpreted as a whole, not as a list of pairs, for the full encoding
> scheme used by the MITRE library, 
Translation aside, this is a list of pairs from an enforcement 
perspective, is it not?
Maybe I'm confused about this, I haven't looked at MLS in detail yet...

=====
How do I tell if s0:c0,c1,c3,c7 is translated as a whole or a list of 
parts. If it's translated as a list of parts, which libsetrans later 
concats using some kind of separator (but are logically independent), I 
want to know what those parts are, and I want them each on a separate 
like in nautilus. If it's interpreted as a whole, then I only want the 
final result. How can I tell? Should I be editing the resultant string? 
What do I present to the user if they want their file accessible by 
s0:c0, and s0:c3, but not the other two.

Also, it seems like the translation is possibly non-unique. If there are 
translation strings for s0:c0,c1, and s0:c3,c7, why are those overridden 
to give precedence to s0:c0,c1,c3,c7. What kind of sorting is applied to 
setrans.conf? Does this make sense in the nautilus case?

--
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: Context translation and MLS categories

[Stephen Smalley]

On Tue, 2006-02-28 at 11:03 -0500, Ivan Gyurdiev wrote:
> Should I be exporting APIs from libsetrans... or from libselinux using 
> libsetrans?

At present, libselinux wraps and exports the libsetrans APIs for context
translation since it has to dlopen it and determine whether translations
are enabled during initialization anyway and libsetrans didn't have a
public API last I looked.  Not sure whether we ultimately want a
separate public libsetrans API called directly by applications.  In the
latter case, there is a potential for mismatches, e.g. application uses
one libsetrans while libselinux uses another.

> Translation aside, this is a list of pairs from an enforcement 
> perspective, is it not?
>
> Maybe I'm confused about this, I haven't looked at MLS in detail yet...

No, not necessarily.  The kernel and libsepol logic is fairly
straightforward, but more elaborate rules end up being applied by
certain kinds of security-aware applications.

> How do I tell if s0:c0,c1,c3,c7 is translated as a whole or a list of 
> parts.

You have to assume as a whole at all times, IMHO.

>  If it's translated as a list of parts, which libsetrans later 
> concats using some kind of separator (but are logically independent), I 
> want to know what those parts are, and I want them each on a separate 
> like in nautilus. If it's interpreted as a whole, then I only want the 
> final result. How can I tell? Should I be editing the resultant string?

I think you just need to treat it as a single blob and only deal with
the final result.  No editing in the application.

> What do I present to the user if they want their file accessible by 
> s0:c0, and s0:c3, but not the other two.

It doesn't work that way - it isn't an ACL.  s0:c0,c3 means that the
file can only be accessed by processes with both c0 and c3 in its
low/sensitivity level (or high/clearance level in the MCS case).  Adding
a category to a file further restricts who can access it - it isn't
additive.

> Also, it seems like the translation is possibly non-unique. If there are 
> translation strings for s0:c0,c1, and s0:c3,c7, why are those overridden 
> to give precedence to s0:c0,c1,c3,c7. What kind of sorting is applied to 
> setrans.conf? Does this make sense in the nautilus case?

I don't know what libsetrans does now, but trying to do partial matches
is likely to produce problems.

-- 
Stephen Smalley
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: Context translation and MLS categories

[Ivan Gyurdiev]

>> What do I present to the user if they want their file accessible by 
>> s0:c0, and s0:c3, but not the other two.
>>     
>
> It doesn't work that way - it isn't an ACL.  s0:c0,c3 means that the
> file can only be accessed by processes with both c0 and c3 in its
> low/sensitivity level (or high/clearance level in the MCS case).  Adding
> a category to a file further restricts who can access it - it isn't
> additive.
>   
Okay... so I am completely misunderstanding this.
That's good to know, before I make critical design mistakes.

I blame James Morris' howto :)
It has no examples with more than one category marked on a file.
============

Okay, how about....

1) We translate the entire range when displaying
2) When modifying the range, we unroll the user's range as (s,c) pairs, 
then translate each of them, and present them as required clearances to 
be added or removed
3) When the range is displayed again, re-translate the whole thing.
============



--
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: Context translation and MLS categories

[Stephen Smalley]

On Tue, 2006-02-28 at 12:08 -0500, Ivan Gyurdiev wrote:
> 1) We translate the entire range when displaying
> 2) When modifying the range, we unroll the user's range as (s,c) pairs, 
> then translate each of them, and present them as required clearances to 
> be added or removed

In general, you can't unroll it in this manner.  It may make sense to do
so for a particular policy (e.g. MCS in particular), but not in the
general case for MLS.

> 3) When the range is displayed again, re-translate the whole thing.

-- 
Stephen Smalley
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: Context translation and MLS categories

[Ivan Gyurdiev]

>> 1) We translate the entire range when displaying
>> 2) When modifying the range, we unroll the user's range as (s,c) pairs, 
>> then translate each of them, and present them as required clearances to 
>> be added or removed
>>     
>
> In general, you can't unroll it in this manner.  It may make sense to do
> so for a particular policy (e.g. MCS in particular), but not in the
> general case for MLS.
>   
Can you give an example?



--
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: Context translation and MLS categories

[Stephen Smalley]

On Tue, 2006-02-28 at 12:35 -0500, Ivan Gyurdiev wrote:
> >> 1) We translate the entire range when displaying
> >> 2) When modifying the range, we unroll the user's range as (s,c) pairs, 
> >> then translate each of them, and present them as required clearances to 
> >> be added or removed
> >>     
> >
> > In general, you can't unroll it in this manner.  It may make sense to do
> > so for a particular policy (e.g. MCS in particular), but not in the
> > general case for MLS.
> >   
> Can you give an example?

http://docs.sun.com/app/docs/doc/805-8123/6j7ktfm62?a=view
http://docs.sun.com/app/docs/doc/805-8123/6j7ktfm7h?a=view

-- 
Stephen Smalley
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.