libsetrans and libselinux

libsetrans and libselinux

[Russell Coker]

Does it make sense to have two separate libraries for these functions?

It seems that they are both maintained by much the same group of people, will 
in many cases need updating at the same time, and will mostly be linked to by 
all the same programs, very few programs need libselinux but not libsetrans 
and that number is constantly decreasing and it's impossible to use 
libsetrans without using libselinux.

If we have a single library then there are some small optimisations that will 
occur, reducing load time and reducing the resident set size by a couple of 
pages.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: libsetrans and libselinux

[Daniel J Walsh]

Russell Coker wrote:
> Does it make sense to have two separate libraries for these functions?
>
> It seems that they are both maintained by much the same group of people, will 
> in many cases need updating at the same time, and will mostly be linked to by 
> all the same programs, very few programs need libselinux but not libsetrans 
> and that number is constantly decreasing and it's impossible to use 
> libsetrans without using libselinux.
>
> If we have a single library then there are some small optimisations that will 
> occur, reducing load time and reducing the resident set size by a couple of 
> pages.
>
>   
The reason they are separate is so that you could build a replacement 
for libsetrans and use it with libselinux.  The idea was someone
might use the Mitre tranaslation library in place of libsetrans.



--
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: libsetrans and libselinux

[Joshua Brindle]

Daniel J Walsh wrote:
> Russell Coker wrote:
> 
>> Does it make sense to have two separate libraries for these functions?
>>
>> It seems that they are both maintained by much the same group of 
>> people, will in many cases need updating at the same time, and will 
>> mostly be linked to by all the same programs, very few programs need 
>> libselinux but not libsetrans and that number is constantly decreasing 
>> and it's impossible to use libsetrans without using libselinux.
>>
>> If we have a single library then there are some small optimisations 
>> that will occur, reducing load time and reducing the resident set size 
>> by a couple of pages.
>>
>>   
> 
> The reason they are separate is so that you could build a replacement 
> for libsetrans and use it with libselinux.  The idea was someone
> might use the Mitre tranaslation library in place of libsetrans.
> 

The only users of libsetrans are ones that use context functions in 
libselinux, and several apps that link to libselinux but don't use those 
(such as load_policy, init, etc)

Further, IIRC libsetrans is being maintained by RH and is not in the nsa 
mainline cvs tree. And as Dan was saying, the whole reason for 
libsetrans to begin with was for drop in translation libraries (such as 
Mitre's)

--
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: libsetrans and libselinux

[Stephen Smalley]

On Tue, 2006-01-03 at 00:55 -0500, Joshua Brindle wrote:
> The only users of libsetrans are ones that use context functions in 
> libselinux, and several apps that link to libselinux but don't use those 
> (such as load_policy, init, etc)
> 
> Further, IIRC libsetrans is being maintained by RH and is not in the nsa 
> mainline cvs tree. And as Dan was saying, the whole reason for 
> libsetrans to begin with was for drop in translation libraries (such as 
> Mitre's)

Yes, Dan earlier proposed integrating libsetrans into libselinux IIRC,
and I resisted.  However, if libsetrans were made suitably generic such
that it wouldn't need to be replaced entirely in order to support things
like the MITRE library, then it might be reasonable to fold it into
libselinux.  It is true that subtle bugs and memory leaks can crop up
now due to the separation.

MITRE also thought it possible that their translation library could be
open sourced, if that would help.  Not sure how long it would take to
gain approval though...

-- 
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: libsetrans and libselinux

[Daniel J Walsh]

Stephen Smalley wrote:
> On Tue, 2006-01-03 at 00:55 -0500, Joshua Brindle wrote:
>   
>> The only users of libsetrans are ones that use context functions in 
>> libselinux, and several apps that link to libselinux but don't use those 
>> (such as load_policy, init, etc)
>>
>> Further, IIRC libsetrans is being maintained by RH and is not in the nsa 
>> mainline cvs tree. And as Dan was saying, the whole reason for 
>> libsetrans to begin with was for drop in translation libraries (such as 
>> Mitre's)
>>     
>
> Yes, Dan earlier proposed integrating libsetrans into libselinux IIRC,
> and I resisted.  However, if libsetrans were made suitably generic such
> that it wouldn't need to be replaced entirely in order to support things
> like the MITRE library, then it might be reasonable to fold it into
> libselinux.  It is true that subtle bugs and memory leaks can crop up
> now due to the separation.
>
>   
There has been some thought to making it daemon based.  And allow 
libsetrans setup a
unix_domain_socket to talk across.  This would allow us to implement a 
daemon and eliminate
the reprocessing of the file each time an application starts.  Then you 
could just replace the daemon.
> MITRE also thought it possible that their translation library could be
> open sourced, if that would help.  Not sure how long it would take to
> gain approval though...
>
>   
I thought there might be classification problems in there also?

--
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: libsetrans and libselinux

[Stephen Smalley]

On Tue, 2006-01-03 at 13:12 -0500, Daniel J Walsh wrote:
> There has been some thought to making it daemon based.  And allow 
> libsetrans setup a
> unix_domain_socket to talk across.  This would allow us to implement a 
> daemon and eliminate
> the reprocessing of the file each time an application starts.  Then you 
> could just replace the daemon.

Right, at that point, one might want to just fold it into libselinux.

> > MITRE also thought it possible that their translation library could be
> > open sourced, if that would help.  Not sure how long it would take to
> > gain approval though...
> >
> >   
> I thought there might be classification problems in there also?

Not for the library itself IIUC.  Just specific configuration files that
might be used.

-- 
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: libsetrans and libselinux

[Daniel J Walsh]

Stephen Smalley wrote:
> On Tue, 2006-01-03 at 13:12 -0500, Daniel J Walsh wrote:
>   
>> There has been some thought to making it daemon based.  And allow 
>> libsetrans setup a
>> unix_domain_socket to talk across.  This would allow us to implement a 
>> daemon and eliminate
>> the reprocessing of the file each time an application starts.  Then you 
>> could just replace the daemon.
>>     
>
> Right, at that point, one might want to just fold it into libselinux.
>
>   
I would wish to move to this new framework before we suck it in.
>>> MITRE also thought it possible that their translation library could be
>>> open sourced, if that would help.  Not sure how long it would take to
>>> gain approval though...
>>>
>>>   
>>>       
>> I thought there might be classification problems in there also?
>>     
>
> Not for the library itself IIUC.  Just specific configuration files that
> might be used.
>
>   


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