Need to break or reduce the dependency on a static libsepol

Need to break or reduce the dependency on a static libsepol

[Stephen Smalley]

This is likely my fault, but we're encountering increasing problems from
growth in the set of things that depend on the static libsepol whenever
we make a change to libsepol, particularly a policy version change.  We
now have (at least) the following dependencies on it:
checkpolicy (always true, not likely to go away)
libselinux (for the audit2why python binding module, which used to be
its own utility in policycoreutils)
setools

Does slide also have this dependency or is it clean?  Anything else to
worry about?

The result is that when a newer libsepol gets incorporated and
libselinux or setools does not, we encounter breakage (unable to find a
policy file they can read or unable to read the policy file at which
they are pointed) or confusion (reading an older policy file left around
from before the libsepol update) upon trying to use audit2why or
setools.

We ran into this problem twice in rawhide / F9, once upon the policy
capability support (policy.22) and now for permissive types (policy.23).

Only real way forward that I can see it to actually encapsulate the
interfaces required by audit2why and setools so that they can use the
shared libsepol.

-- 
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: Need to break or reduce the dependency on a static libsepol

[Joshua Brindle]

Stephen Smalley wrote:
> This is likely my fault, but we're encountering increasing
> problems from growth in the set of things that depend on the
> static libsepol whenever we make a change to libsepol,
> particularly a policy version change.  We now have (at least)
> the following dependencies on it:
> checkpolicy (always true, not likely to go away) libselinux
> (for the audit2why python binding module, which used to be
> its own utility in policycoreutils) setools
> 
> Does slide also have this dependency or is it clean? Anything else to
> worry about? 
> 
> The result is that when a newer libsepol gets incorporated
> and libselinux or setools does not, we encounter breakage
> (unable to find a policy file they can read or unable to read
> the policy file at which they are pointed) or confusion
> (reading an older policy file left around from before the
> libsepol update) upon trying to use audit2why or setools.
> 
> We ran into this problem twice in rawhide / F9, once upon the
> policy capability support (policy.22) and now for permissive types
> (policy.23). 
> 
> Only real way forward that I can see it to actually
> encapsulate the interfaces required by audit2why and setools
> so that they can use the shared libsepol.

One thing that we are doing for policyrep is encapsulating all the "add
this kind of thing to a policydb" functionality because we didn't want
policyrep users to be static libsepol users. 

This has multiple disadvantages including its huge, it is slow (7 hash
lookups to add an av rule currently, since its string based) and doesn't
include the other functionality like the security server, query
functions that would be required for audit2why and setools.

After going through that effort and seeing the pain first hand I
honestly think it is a better alternative to forgo encapsulation and
just make the policydb public. Not yet though, since we ripped out all
the module stuff in it for policyrep. Since it is returning to a more
pristine state that can't realistically change much in the future maybe
it would be better for everyone to rip out the encapsulation as well.


--
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: Need to break or reduce the dependency on a static libsepol

[Joshua Brindle]

Joshua Brindle wrote:
> Stephen Smalley wrote:
>> This is likely my fault, but we're encountering increasing
>> problems from growth in the set of things that depend on the
>> static libsepol whenever we make a change to libsepol,
>> particularly a policy version change.  We now have (at least)
>> the following dependencies on it:
>> checkpolicy (always true, not likely to go away) libselinux
>> (for the audit2why python binding module, which used to be
>> its own utility in policycoreutils) setools
>>
>> Does slide also have this dependency or is it clean? Anything else to
>> worry about? 
>>
>> The result is that when a newer libsepol gets incorporated
>> and libselinux or setools does not, we encounter breakage
>> (unable to find a policy file they can read or unable to read
>> the policy file at which they are pointed) or confusion
>> (reading an older policy file left around from before the
>> libsepol update) upon trying to use audit2why or setools.
>>
>> We ran into this problem twice in rawhide / F9, once upon the
>> policy capability support (policy.22) and now for permissive types
>> (policy.23). 
>>
>> Only real way forward that I can see it to actually
>> encapsulate the interfaces required by audit2why and setools
>> so that they can use the shared libsepol.
> 
> One thing that we are doing for policyrep is encapsulating all the "add
> this kind of thing to a policydb" functionality because we didn't want
> policyrep users to be static libsepol users. 
> 
> This has multiple disadvantages including its huge, it is slow (7 hash
> lookups to add an av rule currently, since its string based) and doesn't
> include the other functionality like the security server, query
> functions that would be required for audit2why and setools.
> 
> After going through that effort and seeing the pain first hand I
> honestly think it is a better alternative to forgo encapsulation and
> just make the policydb public. Not yet though, since we ripped out all
> the module stuff in it for policyrep. Since it is returning to a more
> pristine state that can't realistically change much in the future maybe
> it would be better for everyone to rip out the encapsulation as well.
> 

What are your thoughts on this Steve? Karl agrees with me, the 
encapsulation we have is pretty fake in some places (eg., the interface 
between libsemanage and libsepol) and doesn't help in most others. The 
shared interfaces for everything in libsepol will be _huge_, the ones we 
wrote for policyrep were huge by themselves.

I think libsepol should be the library that knows how to read and write 
a policydb, maybe has a security server implementation but otherwise 
lets people manipulate the policydb however they wish. It would make the 
library much smaller, get rid of the need to statically build and be 
much less work in the long run.

I still think we need to wait until the wide sweeping policyrep changes 
since they remove all the module junk from policydb but after that (or 
perhaps at the same time?) we should just make policydb public and 
slowly remove the unneeded encapsulation.


--
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: Need to break or reduce the dependency on a static libsepol

[Stephen Smalley]

On Wed, 2008-04-02 at 15:56 -0400, Joshua Brindle wrote:
> Joshua Brindle wrote:
> > Stephen Smalley wrote:
> >> This is likely my fault, but we're encountering increasing
> >> problems from growth in the set of things that depend on the
> >> static libsepol whenever we make a change to libsepol,
> >> particularly a policy version change.  We now have (at least)
> >> the following dependencies on it:
> >> checkpolicy (always true, not likely to go away) libselinux
> >> (for the audit2why python binding module, which used to be
> >> its own utility in policycoreutils) setools
> >>
> >> Does slide also have this dependency or is it clean? Anything else to
> >> worry about? 
> >>
> >> The result is that when a newer libsepol gets incorporated
> >> and libselinux or setools does not, we encounter breakage
> >> (unable to find a policy file they can read or unable to read
> >> the policy file at which they are pointed) or confusion
> >> (reading an older policy file left around from before the
> >> libsepol update) upon trying to use audit2why or setools.
> >>
> >> We ran into this problem twice in rawhide / F9, once upon the
> >> policy capability support (policy.22) and now for permissive types
> >> (policy.23). 
> >>
> >> Only real way forward that I can see it to actually
> >> encapsulate the interfaces required by audit2why and setools
> >> so that they can use the shared libsepol.
> > 
> > One thing that we are doing for policyrep is encapsulating all the "add
> > this kind of thing to a policydb" functionality because we didn't want
> > policyrep users to be static libsepol users. 
> > 
> > This has multiple disadvantages including its huge, it is slow (7 hash
> > lookups to add an av rule currently, since its string based) and doesn't
> > include the other functionality like the security server, query
> > functions that would be required for audit2why and setools.
> > 
> > After going through that effort and seeing the pain first hand I
> > honestly think it is a better alternative to forgo encapsulation and
> > just make the policydb public. Not yet though, since we ripped out all
> > the module stuff in it for policyrep. Since it is returning to a more
> > pristine state that can't realistically change much in the future maybe
> > it would be better for everyone to rip out the encapsulation as well.
> > 
> 
> What are your thoughts on this Steve? Karl agrees with me, the 
> encapsulation we have is pretty fake in some places (eg., the interface 
> between libsemanage and libsepol) and doesn't help in most others. The 
> shared interfaces for everything in libsepol will be _huge_, the ones we 
> wrote for policyrep were huge by themselves.
> 
> I think libsepol should be the library that knows how to read and write 
> a policydb, maybe has a security server implementation but otherwise 
> lets people manipulate the policydb however they wish. It would make the 
> library much smaller, get rid of the need to statically build and be 
> much less work in the long run.
> 
> I still think we need to wait until the wide sweeping policyrep changes 
> since they remove all the module junk from policydb but after that (or 
> perhaps at the same time?) we should just make policydb public and 
> slowly remove the unneeded encapsulation.

Well, you know how I feel about encapsulation in general ;)

But what I am not clear about is how we would maintain a stable ABI for
libsepol if we exposed the policydb and its child data structures
directly to the users.  Think back to recent changes (or any of the
changes) we've made to the policydb over time, such as the permissive
type changes, the policy capabilities changes, the pending user
transition changes, etc.  How would we have done that in a way that
preserved a stable libsepol ABI if the policydb had been exposed?

I guess I need to go back and read Ulrich's paper again.

-- 
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: Need to break or reduce the dependency on a static libsepol

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2008-04-02 at 15:56 -0400, Joshua Brindle wrote:
>> Joshua Brindle wrote:
>>> Stephen Smalley wrote:
>>>> This is likely my fault, but we're encountering increasing problems
>>>> from growth in the set of things that depend on the static libsepol
>>>> whenever we make a change to libsepol, particularly a policy
>>>> version change.  We now have (at least) the following dependencies
>>>> on it: checkpolicy (always true, not likely to go away) libselinux
>>>> (for the audit2why python binding module, which used to be its own
>>>> utility in policycoreutils) setools
>>>> 
>>>> Does slide also have this dependency or is it clean? Anything else
>>>> to worry about? 
>>>> 
>>>> The result is that when a newer libsepol gets incorporated and
>>>> libselinux or setools does not, we encounter breakage (unable to
>>>> find a policy file they can read or unable to read the policy file
>>>> at which they are pointed) or confusion (reading an older policy
>>>> file left around from before the libsepol update) upon trying to
>>>> use audit2why or setools. 
>>>> 
>>>> We ran into this problem twice in rawhide / F9, once upon the
>>>> policy capability support (policy.22) and now for permissive types
>>>> (policy.23). 
>>>> 
>>>> Only real way forward that I can see it to actually encapsulate the
>>>> interfaces required by audit2why and setools so that they can use
>>>> the shared libsepol.
>>> 
>>> One thing that we are doing for policyrep is encapsulating all the
>>> "add this kind of thing to a policydb" functionality because we
>>> didn't want policyrep users to be static libsepol users.
>>> 
>>> This has multiple disadvantages including its huge, it is slow (7
>>> hash lookups to add an av rule currently, since its string based)
>>> and doesn't include the other functionality like the security
>>> server, query functions that would be required for audit2why and
>>> setools. 
>>> 
>>> After going through that effort and seeing the pain first hand I
>>> honestly think it is a better alternative to forgo encapsulation and
>>> just make the policydb public. Not yet though, since we ripped out
>>> all the module stuff in it for policyrep. Since it is returning to a
>>> more pristine state that can't realistically change much in the
>>> future maybe it would be better for everyone to rip out the
>>> encapsulation as well. 
>>> 
>> 
>> What are your thoughts on this Steve? Karl agrees with me, the
>> encapsulation we have is pretty fake in some places (eg., the
>> interface between libsemanage and libsepol) and doesn't help in most
>> others. The shared interfaces for everything in libsepol will be
>> _huge_, the ones we wrote for policyrep were huge by themselves.
>> 
>> I think libsepol should be the library that knows how to read and
>> write a policydb, maybe has a security server implementation but
>> otherwise lets people manipulate the policydb however they wish. It
>> would make the library much smaller, get rid of the need to
>> statically build and be much less work in the long run.
>> 
>> I still think we need to wait until the wide sweeping policyrep
>> changes since they remove all the module junk from policydb but after
>> that (or perhaps at the same time?) we should just make policydb
>> public and slowly remove the unneeded encapsulation.
> 
> Well, you know how I feel about encapsulation in general ;)
> 
> But what I am not clear about is how we would maintain a
> stable ABI for libsepol if we exposed the policydb and its
> child data structures directly to the users.  Think back to recent
> changes (or any of the changes) we've made to the policydb over time,
> such as the permissive type changes, the policy capabilities changes,
> the pending user transition changes, etc.  How would we have done
> that in a way that preserved a stable libsepol ABI if the policydb
> had been exposed? 
>

Adding these things to the bottom of the struct (which we did) ensures
no offsets change and the ABI continues to work as expected, no problems
there..
 
OTOH, maintaining legacy interfaces whose usefulness has passed is much
worse.

> I guess I need to go back and read Ulrich's paper again.



--
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: Need to break or reduce the dependency on a static libsepol

[Stephen Smalley]

On Thu, 2008-04-03 at 10:06 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Wed, 2008-04-02 at 15:56 -0400, Joshua Brindle wrote:
> >> Joshua Brindle wrote:
> >>> Stephen Smalley wrote:
> >>>> This is likely my fault, but we're encountering increasing problems
> >>>> from growth in the set of things that depend on the static libsepol
> >>>> whenever we make a change to libsepol, particularly a policy
> >>>> version change.  We now have (at least) the following dependencies
> >>>> on it: checkpolicy (always true, not likely to go away) libselinux
> >>>> (for the audit2why python binding module, which used to be its own
> >>>> utility in policycoreutils) setools
> >>>> 
> >>>> Does slide also have this dependency or is it clean? Anything else
> >>>> to worry about? 
> >>>> 
> >>>> The result is that when a newer libsepol gets incorporated and
> >>>> libselinux or setools does not, we encounter breakage (unable to
> >>>> find a policy file they can read or unable to read the policy file
> >>>> at which they are pointed) or confusion (reading an older policy
> >>>> file left around from before the libsepol update) upon trying to
> >>>> use audit2why or setools. 
> >>>> 
> >>>> We ran into this problem twice in rawhide / F9, once upon the
> >>>> policy capability support (policy.22) and now for permissive types
> >>>> (policy.23). 
> >>>> 
> >>>> Only real way forward that I can see it to actually encapsulate the
> >>>> interfaces required by audit2why and setools so that they can use
> >>>> the shared libsepol.
> >>> 
> >>> One thing that we are doing for policyrep is encapsulating all the
> >>> "add this kind of thing to a policydb" functionality because we
> >>> didn't want policyrep users to be static libsepol users.
> >>> 
> >>> This has multiple disadvantages including its huge, it is slow (7
> >>> hash lookups to add an av rule currently, since its string based)
> >>> and doesn't include the other functionality like the security
> >>> server, query functions that would be required for audit2why and
> >>> setools. 
> >>> 
> >>> After going through that effort and seeing the pain first hand I
> >>> honestly think it is a better alternative to forgo encapsulation and
> >>> just make the policydb public. Not yet though, since we ripped out
> >>> all the module stuff in it for policyrep. Since it is returning to a
> >>> more pristine state that can't realistically change much in the
> >>> future maybe it would be better for everyone to rip out the
> >>> encapsulation as well. 
> >>> 
> >> 
> >> What are your thoughts on this Steve? Karl agrees with me, the
> >> encapsulation we have is pretty fake in some places (eg., the
> >> interface between libsemanage and libsepol) and doesn't help in most
> >> others. The shared interfaces for everything in libsepol will be
> >> _huge_, the ones we wrote for policyrep were huge by themselves.
> >> 
> >> I think libsepol should be the library that knows how to read and
> >> write a policydb, maybe has a security server implementation but
> >> otherwise lets people manipulate the policydb however they wish. It
> >> would make the library much smaller, get rid of the need to
> >> statically build and be much less work in the long run.
> >> 
> >> I still think we need to wait until the wide sweeping policyrep
> >> changes since they remove all the module junk from policydb but after
> >> that (or perhaps at the same time?) we should just make policydb
> >> public and slowly remove the unneeded encapsulation.
> > 
> > Well, you know how I feel about encapsulation in general ;)
> > 
> > But what I am not clear about is how we would maintain a
> > stable ABI for libsepol if we exposed the policydb and its
> > child data structures directly to the users.  Think back to recent
> > changes (or any of the changes) we've made to the policydb over time,
> > such as the permissive type changes, the policy capabilities changes,
> > the pending user transition changes, etc.  How would we have done
> > that in a way that preserved a stable libsepol ABI if the policydb
> > had been exposed? 
> >
> 
> Adding these things to the bottom of the struct (which we did) ensures
> no offsets change and the ABI continues to work as expected, no problems
> there..

Not so clear to me.  If the policydb and its sub-structures were public,
and an application or another library directly allocated one itself on
the stack or on the heap, and passed it in as an argument to a libsepol
function, then if we later add fields to the end of the structure and
libsepol tries to access those fields on an input argument, things will
go boom.  I think we'd have to version the data structures themselves,
and on all of them, not just the policydb.  And not all changes are
purely additive, e.g. the optimization of the avtab comes to mind.

> OTOH, maintaining legacy interfaces whose usefulness has passed is much
> worse.

Yes, that is certainly a problem we have presently, as shown in the
legacy setlocaldefs support for booleans and users.

> 
> > I guess I need to go back and read Ulrich's paper again.
> 
-- 
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: Need to break or reduce the dependency on a static libsepol

[Stephen Smalley]

On Thu, 2008-04-03 at 10:15 -0400, Stephen Smalley wrote:
> On Thu, 2008-04-03 at 10:06 -0400, Joshua Brindle wrote:
> > Stephen Smalley wrote:
> > > On Wed, 2008-04-02 at 15:56 -0400, Joshua Brindle wrote:
> > >> Joshua Brindle wrote:
> > >>> Stephen Smalley wrote:
> > >>>> This is likely my fault, but we're encountering increasing problems
> > >>>> from growth in the set of things that depend on the static libsepol
> > >>>> whenever we make a change to libsepol, particularly a policy
> > >>>> version change.  We now have (at least) the following dependencies
> > >>>> on it: checkpolicy (always true, not likely to go away) libselinux
> > >>>> (for the audit2why python binding module, which used to be its own
> > >>>> utility in policycoreutils) setools
> > >>>> 
> > >>>> Does slide also have this dependency or is it clean? Anything else
> > >>>> to worry about? 
> > >>>> 
> > >>>> The result is that when a newer libsepol gets incorporated and
> > >>>> libselinux or setools does not, we encounter breakage (unable to
> > >>>> find a policy file they can read or unable to read the policy file
> > >>>> at which they are pointed) or confusion (reading an older policy
> > >>>> file left around from before the libsepol update) upon trying to
> > >>>> use audit2why or setools. 
> > >>>> 
> > >>>> We ran into this problem twice in rawhide / F9, once upon the
> > >>>> policy capability support (policy.22) and now for permissive types
> > >>>> (policy.23). 
> > >>>> 
> > >>>> Only real way forward that I can see it to actually encapsulate the
> > >>>> interfaces required by audit2why and setools so that they can use
> > >>>> the shared libsepol.
> > >>> 
> > >>> One thing that we are doing for policyrep is encapsulating all the
> > >>> "add this kind of thing to a policydb" functionality because we
> > >>> didn't want policyrep users to be static libsepol users.
> > >>> 
> > >>> This has multiple disadvantages including its huge, it is slow (7
> > >>> hash lookups to add an av rule currently, since its string based)
> > >>> and doesn't include the other functionality like the security
> > >>> server, query functions that would be required for audit2why and
> > >>> setools. 
> > >>> 
> > >>> After going through that effort and seeing the pain first hand I
> > >>> honestly think it is a better alternative to forgo encapsulation and
> > >>> just make the policydb public. Not yet though, since we ripped out
> > >>> all the module stuff in it for policyrep. Since it is returning to a
> > >>> more pristine state that can't realistically change much in the
> > >>> future maybe it would be better for everyone to rip out the
> > >>> encapsulation as well. 
> > >>> 
> > >> 
> > >> What are your thoughts on this Steve? Karl agrees with me, the
> > >> encapsulation we have is pretty fake in some places (eg., the
> > >> interface between libsemanage and libsepol) and doesn't help in most
> > >> others. The shared interfaces for everything in libsepol will be
> > >> _huge_, the ones we wrote for policyrep were huge by themselves.
> > >> 
> > >> I think libsepol should be the library that knows how to read and
> > >> write a policydb, maybe has a security server implementation but
> > >> otherwise lets people manipulate the policydb however they wish. It
> > >> would make the library much smaller, get rid of the need to
> > >> statically build and be much less work in the long run.
> > >> 
> > >> I still think we need to wait until the wide sweeping policyrep
> > >> changes since they remove all the module junk from policydb but after
> > >> that (or perhaps at the same time?) we should just make policydb
> > >> public and slowly remove the unneeded encapsulation.
> > > 
> > > Well, you know how I feel about encapsulation in general ;)
> > > 
> > > But what I am not clear about is how we would maintain a
> > > stable ABI for libsepol if we exposed the policydb and its
> > > child data structures directly to the users.  Think back to recent
> > > changes (or any of the changes) we've made to the policydb over time,
> > > such as the permissive type changes, the policy capabilities changes,
> > > the pending user transition changes, etc.  How would we have done
> > > that in a way that preserved a stable libsepol ABI if the policydb
> > > had been exposed? 
> > >
> > 
> > Adding these things to the bottom of the struct (which we did) ensures
> > no offsets change and the ABI continues to work as expected, no problems
> > there..
> 
> Not so clear to me.  If the policydb and its sub-structures were public,
> and an application or another library directly allocated one itself on
> the stack or on the heap, and passed it in as an argument to a libsepol
> function, then if we later add fields to the end of the structure and
> libsepol tries to access those fields on an input argument, things will
> go boom.  I think we'd have to version the data structures themselves,
> and on all of them, not just the policydb.  And not all changes are
> purely additive, e.g. the optimization of the avtab comes to mind.

Ulrich's good practices in library design, implementation, and
maintenance lays out a few ways of doing this, including requiring the
caller to invoke a function in advance to specify the desired version
ala elf_version (but this breaks down when there are multiple users of
the library from the same program, possibly from other shared objects as
well), putting a version field in each data structure (but this carries
an obvious cost in storage and runtime), and specifying the version in
the interface, hidden via macros ala the stat structure and calls which
operate on it (see /usr/include/sys/stat.h).

-- 
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: Need to break or reduce the dependency on a static libsepol

[Joshua Brindle]

Stephen Smalley wrote:
> On Thu, 2008-04-03 at 10:06 -0400, Joshua Brindle wrote:
>> Stephen Smalley wrote:
>>> On Wed, 2008-04-02 at 15:56 -0400, Joshua Brindle wrote:
>>>> Joshua Brindle wrote:
>>>>> Stephen Smalley wrote:
>>>>>> This is likely my fault, but we're encountering increasing problems
>>>>>> from growth in the set of things that depend on the static libsepol
>>>>>> whenever we make a change to libsepol, particularly a policy
>>>>>> version change.  We now have (at least) the following dependencies
>>>>>> on it: checkpolicy (always true, not likely to go away) libselinux
>>>>>> (for the audit2why python binding module, which used to be its own
>>>>>> utility in policycoreutils) setools
>>>>>>
>>>>>> Does slide also have this dependency or is it clean? Anything else
>>>>>> to worry about? 
>>>>>>
>>>>>> The result is that when a newer libsepol gets incorporated and
>>>>>> libselinux or setools does not, we encounter breakage (unable to
>>>>>> find a policy file they can read or unable to read the policy file
>>>>>> at which they are pointed) or confusion (reading an older policy
>>>>>> file left around from before the libsepol update) upon trying to
>>>>>> use audit2why or setools. 
>>>>>>
>>>>>> We ran into this problem twice in rawhide / F9, once upon the
>>>>>> policy capability support (policy.22) and now for permissive types
>>>>>> (policy.23). 
>>>>>>
>>>>>> Only real way forward that I can see it to actually encapsulate the
>>>>>> interfaces required by audit2why and setools so that they can use
>>>>>> the shared libsepol.
>>>>> One thing that we are doing for policyrep is encapsulating all the
>>>>> "add this kind of thing to a policydb" functionality because we
>>>>> didn't want policyrep users to be static libsepol users.
>>>>>
>>>>> This has multiple disadvantages including its huge, it is slow (7
>>>>> hash lookups to add an av rule currently, since its string based)
>>>>> and doesn't include the other functionality like the security
>>>>> server, query functions that would be required for audit2why and
>>>>> setools. 
>>>>>
>>>>> After going through that effort and seeing the pain first hand I
>>>>> honestly think it is a better alternative to forgo encapsulation and
>>>>> just make the policydb public. Not yet though, since we ripped out
>>>>> all the module stuff in it for policyrep. Since it is returning to a
>>>>> more pristine state that can't realistically change much in the
>>>>> future maybe it would be better for everyone to rip out the
>>>>> encapsulation as well. 
>>>>>
>>>> What are your thoughts on this Steve? Karl agrees with me, the
>>>> encapsulation we have is pretty fake in some places (eg., the
>>>> interface between libsemanage and libsepol) and doesn't help in most
>>>> others. The shared interfaces for everything in libsepol will be
>>>> _huge_, the ones we wrote for policyrep were huge by themselves.
>>>>
>>>> I think libsepol should be the library that knows how to read and
>>>> write a policydb, maybe has a security server implementation but
>>>> otherwise lets people manipulate the policydb however they wish. It
>>>> would make the library much smaller, get rid of the need to
>>>> statically build and be much less work in the long run.
>>>>
>>>> I still think we need to wait until the wide sweeping policyrep
>>>> changes since they remove all the module junk from policydb but after
>>>> that (or perhaps at the same time?) we should just make policydb
>>>> public and slowly remove the unneeded encapsulation.
>>> Well, you know how I feel about encapsulation in general ;)
>>>
>>> But what I am not clear about is how we would maintain a
>>> stable ABI for libsepol if we exposed the policydb and its
>>> child data structures directly to the users.  Think back to recent
>>> changes (or any of the changes) we've made to the policydb over time,
>>> such as the permissive type changes, the policy capabilities changes,
>>> the pending user transition changes, etc.  How would we have done
>>> that in a way that preserved a stable libsepol ABI if the policydb
>>> had been exposed? 
>>>
>> Adding these things to the bottom of the struct (which we did) ensures
>> no offsets change and the ABI continues to work as expected, no problems
>> there..
> 
> Not so clear to me.  If the policydb and its sub-structures were public,
> and an application or another library directly allocated one itself on
> the stack or on the heap, and passed it in as an argument to a libsepol
> function, then if we later add fields to the end of the structure and
> libsepol tries to access those fields on an input argument, things will
> go boom.  I think we'd have to version the data structures themselves,
> and on all of them, not just the policydb.  And not all changes are
> purely additive, e.g. the optimization of the avtab comes to mind.
> 

So the policydb that can be put on the stack would just have a pointer 
to the real policydb struct and problem solved. I'm thinking about the 
need to version all the sub structs.. This has got to be doable, how do 
people do it elsewhere?

>> OTOH, maintaining legacy interfaces whose usefulness has passed is much
>> worse.
> 
> Yes, that is certainly a problem we have presently, as shown in the
> legacy setlocaldefs support for booleans and users.
> 
>>> I guess I need to go back and read Ulrich's paper again.

Fair enough, maybe I'll take a look as well.


--
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: Need to break or reduce the dependency on a static libsepol

[David Sugar]

Steve,

SLIDE does not have any dependency on libsepol.  But in what we are
working on for CDS Framework we have recently introduced dependencies on
the static libsepol.  We need to be able to query the policy to verify
that any particular allow rules have been put in place.  This is
specifically important when MLS is enabled to verify that MLS
constraints are not denying an access.

I don't remember off the top of my head exactly which functions are
being used from the static libsepol but I know there were a few things
that were not exported in the shared object and Josh said to use the
static version.

Dave

On Tue, 2008-04-01 at 08:07 -0400, Stephen Smalley wrote:
> This is likely my fault, but we're encountering increasing problems from
> growth in the set of things that depend on the static libsepol whenever
> we make a change to libsepol, particularly a policy version change.  We
> now have (at least) the following dependencies on it:
> checkpolicy (always true, not likely to go away)
> libselinux (for the audit2why python binding module, which used to be
> its own utility in policycoreutils)
> setools
> 
> Does slide also have this dependency or is it clean?  Anything else to
> worry about?
> 
> The result is that when a newer libsepol gets incorporated and
> libselinux or setools does not, we encounter breakage (unable to find a
> policy file they can read or unable to read the policy file at which
> they are pointed) or confusion (reading an older policy file left around
> from before the libsepol update) upon trying to use audit2why or
> setools.
> 
> We ran into this problem twice in rawhide / F9, once upon the policy
> capability support (policy.22) and now for permissive types (policy.23).
> 
> Only real way forward that I can see it to actually encapsulate the
> interfaces required by audit2why and setools so that they can use the
> shared libsepol.
> 


--
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: Need to break or reduce the dependency on a static libsepol

[Stephen Smalley]

On Tue, 2008-04-01 at 14:27 -0400, David Sugar wrote:
> Steve,
> 
> SLIDE does not have any dependency on libsepol.  But in what we are
> working on for CDS Framework we have recently introduced dependencies on
> the static libsepol.  We need to be able to query the policy to verify
> that any particular allow rules have been put in place.  This is
> specifically important when MLS is enabled to verify that MLS
> constraints are not denying an access.
> 
> I don't remember off the top of my head exactly which functions are
> being used from the static libsepol but I know there were a few things
> that were not exported in the shared object and Josh said to use the
> static version.

Don't know if this helps, but audit2why will tell you whether or not a
denial is due to a constraint violation (not specifically MLS, but any
constraint).  And libselinux now provides a python binding to audit2why.
If you can use that or extend it, then we at least don't add one more
copy of the static libsepol on the system.

> Dave
> 
> On Tue, 2008-04-01 at 08:07 -0400, Stephen Smalley wrote:
> > This is likely my fault, but we're encountering increasing problems from
> > growth in the set of things that depend on the static libsepol whenever
> > we make a change to libsepol, particularly a policy version change.  We
> > now have (at least) the following dependencies on it:
> > checkpolicy (always true, not likely to go away)
> > libselinux (for the audit2why python binding module, which used to be
> > its own utility in policycoreutils)
> > setools
> > 
> > Does slide also have this dependency or is it clean?  Anything else to
> > worry about?
> > 
> > The result is that when a newer libsepol gets incorporated and
> > libselinux or setools does not, we encounter breakage (unable to find a
> > policy file they can read or unable to read the policy file at which
> > they are pointed) or confusion (reading an older policy file left around
> > from before the libsepol update) upon trying to use audit2why or
> > setools.
> > 
> > We ran into this problem twice in rawhide / F9, once upon the policy
> > capability support (policy.22) and now for permissive types (policy.23).
> > 
> > Only real way forward that I can see it to actually encapsulate the
> > interfaces required by audit2why and setools so that they can use the
> > shared libsepol.
> > 
-- 
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: Need to break or reduce the dependency on a static libsepol

[Dave Sugar]

On Tue, 2008-04-01 at 15:01 -0400, Stephen Smalley wrote:
> On Tue, 2008-04-01 at 14:27 -0400, David Sugar wrote:
> > Steve,
> > 
> > SLIDE does not have any dependency on libsepol.  But in what we are
> > working on for CDS Framework we have recently introduced dependencies on
> > the static libsepol.  We need to be able to query the policy to verify
> > that any particular allow rules have been put in place.  This is
> > specifically important when MLS is enabled to verify that MLS
> > constraints are not denying an access.
> > 
> > I don't remember off the top of my head exactly which functions are
> > being used from the static libsepol but I know there were a few things
> > that were not exported in the shared object and Josh said to use the
> > static version.
> 
> Don't know if this helps, but audit2why will tell you whether or not a
> denial is due to a constraint violation (not specifically MLS, but any
> constraint).  And libselinux now provides a python binding to audit2why.
> If you can use that or extend it, then we at least don't add one more
> copy of the static libsepol on the system.
> 

Of course CDS Framework is Java and we wrote just enough Java SWIG
bindings to get what we needed out of libsepol.  We don't have an audit
message we actually are checking the graphically designed policy for
what allows should be there and making sure they all are truly allowed.

Josh has suggested we put the SWIG bindings into libsepol.  And I'm in
favor of that, but it is not complete because it is only what we are
using in CDS Framework.  

> > Dave
> > 
> > On Tue, 2008-04-01 at 08:07 -0400, Stephen Smalley wrote:
> > > This is likely my fault, but we're encountering increasing problems from
> > > growth in the set of things that depend on the static libsepol whenever
> > > we make a change to libsepol, particularly a policy version change.  We
> > > now have (at least) the following dependencies on it:
> > > checkpolicy (always true, not likely to go away)
> > > libselinux (for the audit2why python binding module, which used to be
> > > its own utility in policycoreutils)
> > > setools
> > > 
> > > Does slide also have this dependency or is it clean?  Anything else to
> > > worry about?
> > > 
> > > The result is that when a newer libsepol gets incorporated and
> > > libselinux or setools does not, we encounter breakage (unable to find a
> > > policy file they can read or unable to read the policy file at which
> > > they are pointed) or confusion (reading an older policy file left around
> > > from before the libsepol update) upon trying to use audit2why or
> > > setools.
> > > 
> > > We ran into this problem twice in rawhide / F9, once upon the policy
> > > capability support (policy.22) and now for permissive types (policy.23).
> > > 
> > > Only real way forward that I can see it to actually encapsulate the
> > > interfaces required by audit2why and setools so that they can use the
> > > shared libsepol.
> > > 

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