Mls data structure, Seusers...

Mls data structure, Seusers...

[Ivan Gyurdiev]

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.

Re: Mls data structure, Seusers...

[Stephen Smalley]

On Sat, 2005-11-12 at 15:17 -0500, Ivan Gyurdiev wrote:
> 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.

I think using a string for the MLS data is fine.  I see no gain from
further data hiding beyond that level.

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

I don't think we want to move in that direction; seuser records should
not be a sepol abstraction at all.

-- 
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: Mls data structure, Seusers...

[Ivan Gyurdiev]

>> 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.
>>     
>
> I think using a string for the MLS data is fine.  I see no gain from
> further data hiding beyond that level.
>   
Allright - in that case I will write char* interfaces to manage mls 
levels/ranges in libsepol, and expose those. Those interfaces will need 
to be made abstract as well - can't rely on the policydb object.

It's kind of a strange situation - imagine sysadmin on machine A wants 
to modify policy (possibly originating from a remote machine B), and to 
do that libsemanage validates seuser data, which could be on LDAP server C.

>> 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.
>>     
>
> I don't think we want to move in that direction; seuser records should
> not be a sepol abstraction at all.
>   
Sure, I was just listing the possibilities. 


--
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: Mls data structure, Seusers...

[Chad Hanson]

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.