Research
.
Skip Search Box

SELinux Mailing List

RE: Mls data structure, Seusers...

From: Chad Hanson <chanson_at_TrustedCS.com>
Date: Mon, 14 Nov 2005 10:11:30 -0500

The two pieces of MLS data associated with a user are the default level and range. I am not really up to date with library development, but these two items are both strings in the untranslated policy format.

-Chad

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:ivg2@cornell.edu]
> Sent: Saturday, November 12, 2005 2:18 PM
> To: SELinux List; SELinux-dev@tresys.com
> Cc: Stephen Smalley
> Subject: Mls data structure, Seusers...
>
>
> Okay, I think sepol is moving on the right track to becoming a properly
> encapsulated library. Opaque structures are being used in interfaces,
> which is important to maintain stability in the future. There has been
> disagreement in the past as to whether separate data structures
> (records) should be created to manage various objects, or whether the
> existing structures should be used. I think that issue's less important
> than using opaque structures in the interface - if the interface is set
> up correctly, the internals can be easily changed. I still favor
> separate data structures, because they are independent from policy (so
> can be serialized and passed to the client by the policy server, without
> needing the policy after the initial query), and because they're higher
> level, and easier to work with from the client's perspective.
>
> Anyway, to get to the point of this email... I originally chose to
> represent MLS data in user/seuser/context objects as a string, rather
> than a structure. That might have been a mistake, so I raise this issue
> again - is a string acceptable? It's important to clarify this, because
> it affects the interface, and also matters for future functions which I
> plan to write that allow libsemanage to validate seuser mls fields.
>
> By the way, I am assuming that the way this will be done is by
> introducing (shared) interfaces to deal with mls ranges/levels. An
> alternative approach is to make sepol learn about seusers (by moving the
> seuser record into sepol), and dealing with this higher-level object,
> rather than the mls range directly. However, there's no reason to move
> the seuser record into sepol, other than for validation - seusers are
> not loaded into policy.
>

--
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.
Received on Mon 14 Nov 2005 - 10:25:59 EST
 

Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009

 
bottom

National Security Agency / Central Security Service