releasibility in mcstransd

releasibility in mcstransd

[Joshua Brindle]

I am adding releasibility support to mcstransd and just wanted to see if there were any comments or complaints to what I'm planning here.

Rather than adding a generic prefix mechanism like the CMW encodings I did something specific for releasibility, in setrans.conf:

releasibility c100.c128

then encodings look like:

s0:~c100 = rel_US
s0:~c101 = rel_Texas

so a file with s0:c102.c128 would translate to s0:rel_US,rel_Texas.

any comments? Does anyone think this is absolutely the wrong approach?


--
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: releasibility in mcstransd

[Paul Moore]

On Monday 09 June 2008 4:25:31 pm Joshua Brindle wrote:
> I am adding releasibility support to mcstransd and just wanted to see
> if there were any comments or complaints to what I'm planning here.
>
> Rather than adding a generic prefix mechanism like the CMW encodings
> I did something specific for releasibility, in setrans.conf:
>
> releasibility c100.c128
>
> then encodings look like:
>
> s0:~c100 = rel_US
> s0:~c101 = rel_Texas
>
> so a file with s0:c102.c128 would translate to s0:rel_US,rel_Texas.
>
> any comments? Does anyone think this is absolutely the wrong
> approach?

Unless there is a reason to do away with the existing CMW convention I 
think we should probably stick with it for no other reason than it is 
familiar to users migrating from CMW boxes to SELinux.

-- 
paul moore
linux @ hp

--
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: releasibility in mcstransd

[Chad Hanson]

 
Seems reasonable to me unless you want to create a nice new encoding
language ;)

How would the user process translate, eg, s0:c102.c128, just s0?

-Chad 

> 
> I am adding releasibility support to mcstransd and just 
> wanted to see if there were any comments or complaints to 
> what I'm planning here.
> 
> Rather than adding a generic prefix mechanism like the CMW 
> encodings I did something specific for releasibility, in setrans.conf:
> 
> releasibility c100.c128
> 
> then encodings look like:
> 
> s0:~c100 = rel_US
> s0:~c101 = rel_Texas
> 
> so a file with s0:c102.c128 would translate to s0:rel_US,rel_Texas.
> 
> any comments? Does anyone think this is absolutely the wrong approach?
> 
> 


--
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: releasibility in mcstransd

[Joe Nall]

[-- Attachment #1: Type: text/plain, Size: 2387 bytes --]


On Jun 9, 2008, at 4:04 PM, Chad Hanson wrote:

>
> Seems reasonable to me unless you want to create a nice new encoding
> language ;)
>
> How would the user process translate, eg, s0:c102.c128, just s0?
>
> -Chad

Attached is a source rpm based on the mcstransd we are using  
internally. It can translate ranges that look like:

Secret Releasable to USA/FRA/DEU/ZWI
Confidential Rel GBR
Secret A
Secret Noforn
Secret Rel to USA/GBR-Secret Noforn
Restricted Handle Via Iron,Plastic,Copper Pipes Only-Restricted Handle  
Via Iron Pipes Only
...

It supports the idea of default inverse bits, multiple domains of  
translation (still needs some protocol support) and aliases for levels  
and compartments. The example setrans.conf include an implementation  
of releasabilities based on ISO 3166 three letter country codes and  
FIPS-10 two letter country codes pulled from the CIA World Factbook.  
Any combination or permutation of releasabilities with arbitrary  
prefix and suffix is supported.

There is an include mechanism to allow segregating category  
configuration into separate files of related words and a python test  
harness with the tests in separate files.

We have used the code internally to translate the US CAPCO markings  
standard (minus the words with '-' in them).

I've been meaning to release it for the better part of a year and  
Josh's email persuaded me to go ahead even though there are a number  
of things remaining on the TO DO list:
  - a simple constraints language so you can say that categories foo  
and bar can not be in the same level together.
  - finish the multiple domain of translation support (multiple  
languages and paragraph markings)
  - more hardening
  - better first translation performance (subsequent translations are  
cached)
  - words with embedded '-'
  - man pages :(

There is a README in the conf directory describing the configuration  
file format and a number of examples in the sample configuration and  
test files.

To install and test (as root in MLS/Permissive)

rpm -ivh mcstrans-0.3.0-1.jnall.src.rpm
rpmbuild -bb /usr/src/redhat/SPECS/mcstrans.spec
rpm -Uvh /usr/src/redhat/RPMS/*/mcstrans-*.rpm

cd /usr/src/redhat/BUILD/mcstrans-0.3.0/conf
cp -rp setrans.conf setrans.d /etc/selinux/mls/
restorecon -rv /etc/selinux/mls
service mcstrans restart

cd /usr/src/redhat/BUILD/mcstrans-0.3.0/utils
make test

joe


[-- Attachment #2: mcstrans-0.3.0-1.jnall.src.rpm --]
[-- Type: application/vnd.rn-realmedia, Size: 49562 bytes --]

Re: releasibility in mcstransd

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joe Nall wrote:
|
| On Jun 9, 2008, at 4:04 PM, Chad Hanson wrote:
|
|>
|> Seems reasonable to me unless you want to create a nice new encoding
|> language ;)
|>
|> How would the user process translate, eg, s0:c102.c128, just s0?
|>
|> -Chad
|
| Attached is a source rpm based on the mcstransd we are using internally.
| It can translate ranges that look like:
|
| Secret Releasable to USA/FRA/DEU/ZWI
| Confidential Rel GBR
| Secret A
| Secret Noforn
| Secret Rel to USA/GBR-Secret Noforn
| Restricted Handle Via Iron,Plastic,Copper Pipes Only-Restricted Handle
| Via Iron Pipes Only
| ...
|
| It supports the idea of default inverse bits, multiple domains of
| translation (still needs some protocol support) and aliases for levels
| and compartments. The example setrans.conf include an implementation of
| releasabilities based on ISO 3166 three letter country codes and FIPS-10
| two letter country codes pulled from the CIA World Factbook. Any
| combination or permutation of releasabilities with arbitrary prefix and
| suffix is supported.
|
| There is an include mechanism to allow segregating category
| configuration into separate files of related words and a python test
| harness with the tests in separate files.
|
| We have used the code internally to translate the US CAPCO markings
| standard (minus the words with '-' in them).
|
| I've been meaning to release it for the better part of a year and Josh's
| email persuaded me to go ahead even though there are a number of things
| remaining on the TO DO list:
|  - a simple constraints language so you can say that categories foo and
| bar can not be in the same level together.
|  - finish the multiple domain of translation support (multiple languages
| and paragraph markings)
|  - more hardening
|  - better first translation performance (subsequent translations are
| cached)
|  - words with embedded '-'
|  - man pages :(
|
| There is a README in the conf directory describing the configuration
| file format and a number of examples in the sample configuration and
| test files.
|
| To install and test (as root in MLS/Permissive)
|
| rpm -ivh mcstrans-0.3.0-1.jnall.src.rpm
| rpmbuild -bb /usr/src/redhat/SPECS/mcstrans.spec
| rpm -Uvh /usr/src/redhat/RPMS/*/mcstrans-*.rpm
|
| cd /usr/src/redhat/BUILD/mcstrans-0.3.0/conf
| cp -rp setrans.conf setrans.d /etc/selinux/mls/
| restorecon -rv /etc/selinux/mls
| service mcstrans restart
|
| cd /usr/src/redhat/BUILD/mcstrans-0.3.0/utils
| make test
|
| joe
|
Please review this patch, the people who understand it  :^(.  And I will
update the Fedora package if it works for everyone.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhP3QsACgkQrlYvE4MpobM+VACgpDenfOo53Yca6FdI8j3tnoKl
qjEAoJUg/D09b7vmaMuDO3qKoxC3TcYk
=wSch
-----END PGP SIGNATURE-----

--
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: releasibility in mcstransd

[Joshua Brindle]

Joe Nall wrote:
> 
> On Jun 9, 2008, at 4:04 PM, Chad Hanson wrote:
> 
>>
>> Seems reasonable to me unless you want to create a nice new encoding
>> language ;)
>>
>> How would the user process translate, eg, s0:c102.c128, just s0?
>>
>> -Chad
> 
> Attached is a source rpm based on the mcstransd we are using internally.
> It can translate ranges that look like:
> 
> Secret Releasable to USA/FRA/DEU/ZWI
> Confidential Rel GBR
> Secret A
> Secret Noforn
> Secret Rel to USA/GBR-Secret Noforn
> Restricted Handle Via Iron,Plastic,Copper Pipes Only-Restricted Handle
> Via Iron Pipes Only
> ...
> 
> It supports the idea of default inverse bits, multiple domains of
> translation (still needs some protocol support) and aliases for levels
> and compartments. The example setrans.conf include an implementation of
> releasabilities based on ISO 3166 three letter country codes and FIPS-10
> two letter country codes pulled from the CIA World Factbook. Any
> combination or permutation of releasabilities with arbitrary prefix and
> suffix is supported.
> 
> There is an include mechanism to allow segregating category
> configuration into separate files of related words and a python test
> harness with the tests in separate files.
> 
> We have used the code internally to translate the US CAPCO markings
> standard (minus the words with '-' in them).
> 
> I've been meaning to release it for the better part of a year and Josh's
> email persuaded me to go ahead even though there are a number of things
> remaining on the TO DO list:
>  - a simple constraints language so you can say that categories foo and
> bar can not be in the same level together.
>  - finish the multiple domain of translation support (multiple languages
> and paragraph markings)
>  - more hardening
>  - better first translation performance (subsequent translations are
> cached)
>  - words with embedded '-'
>  - man pages :(
> 
> There is a README in the conf directory describing the configuration
> file format and a number of examples in the sample configuration and
> test files.
> 
> To install and test (as root in MLS/Permissive)
> 
> rpm -ivh mcstrans-0.3.0-1.jnall.src.rpm
> rpmbuild -bb /usr/src/redhat/SPECS/mcstrans.spec
> rpm -Uvh /usr/src/redhat/RPMS/*/mcstrans-*.rpm
> 
> cd /usr/src/redhat/BUILD/mcstrans-0.3.0/conf
> cp -rp setrans.conf setrans.d /etc/selinux/mls/
> restorecon -rv /etc/selinux/mls
> service mcstrans restart
> 
> cd /usr/src/redhat/BUILD/mcstrans-0.3.0/utils
> make test
> 

Thanks for this. I started looking at the diff and it is pretty significant, it might take me a while to get through it all. One thing I noticed immediately is that you are duplicating interfaces present in libsepol such as mls_level_to_string, mls_level_from_string and importing private headers from libsepol. 

I don't think we want to proceed this way. If possible we should be using the libsepol interfaces and encapsulating the private types as necessary.

The ebitmap operations can certainly be put in libsepol but shouldn't be called directly the way they are.

It looks like quite a few todo's and hacks are in there as well. I'll try to help as much as I can, and hopefully we can get this in good shape to merge in to Dan's codebase. Are you going to have any time to work on this?


--
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: releasibility in mcstransd

[Joe Nall]

On Jun 20, 2008, at 10:37 AM, Joshua Brindle wrote:

> Joe Nall wrote:
>>
>> ...
>> Attached is a source rpm based on the mcstransd we are using  
>> internally.
>> It can translate ranges that look like:
>>
> Thanks for this. I started looking at the diff and it is pretty  
> significant, it might take me a while to get through it all. One  
> thing I noticed immediately is that you are duplicating interfaces  
> present in libsepol such as mls_level_to_string,  
> mls_level_from_string and importing private headers from libsepol.

IIRC, the functions were not exported. I'm more than willing to drop  
those routines and use libsepol.

> I don't think we want to proceed this way. If possible we should be  
> using the libsepol interfaces and encapsulating the private types as  
> necessary.

I agree

> The ebitmap operations can certainly be put in libsepol but  
> shouldn't be called directly the way they are.

I like to putting the additional ebitmap functions in libsepol. I was  
hoping Stephen would make them faster too :) I don't understand the  
'shouldn't be called directly the way they are' comment.

> It looks like quite a few todo's and hacks are in there as well.

Yep. It got to this mostly workable state some time ago and other  
things have taken precedence since.

> I'll try to help as much as I can, and hopefully we can get this in  
> good shape to merge in to Dan's codebase. Are you going to have any  
> time to work on this?

Yes. I really want to get some conversion constraints in before OLS.  
Things like REL and NOFORN don't go together. An interface to export  
which bits are 'inverse' would be very handy within our applications  
code. The semanage translation code is broken/obsoleted by these  
changes too.

joe

--
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: releasibility in mcstransd

[Joshua Brindle]

Joe Nall wrote:
> 
> On Jun 20, 2008, at 10:37 AM, Joshua Brindle wrote:
> 
>> Joe Nall wrote:
>>>
>>> ...
>>> Attached is a source rpm based on the mcstransd we are using internally.
>>> It can translate ranges that look like:
>>>
>> Thanks for this. I started looking at the diff and it is pretty
>> significant, it might take me a while to get through it all. One thing
>> I noticed immediately is that you are duplicating interfaces present
>> in libsepol such as mls_level_to_string, mls_level_from_string and
>> importing private headers from libsepol.
> 
> IIRC, the functions were not exported. I'm more than willing to drop
> those routines and use libsepol.
> 
>> I don't think we want to proceed this way. If possible we should be
>> using the libsepol interfaces and encapsulating the private types as
>> necessary.
> 
> I agree
> 

Stephen: What do you think we should do about this? We've talked about losing some of the encapsulation in libsepol but that was related to policydb. Should we just export the mls types for now and use those or continue by making them opaque? Since this mcstrans does alot of operations on them it might make making them opaque difficult. We could probably move alot of the functionality out of mcstrans and in to libsepol but that would be coupling our libs to this particular translation scheme which I thought we were trying to avoid?

>> The ebitmap operations can certainly be put in libsepol but shouldn't
>> be called directly the way they are.
> 
> I like to putting the additional ebitmap functions in libsepol. I was
> hoping Stephen would make them faster too :) I don't understand the
> 'shouldn't be called directly the way they are' comment.
> 

ebitmaps aren't exported so you'd never actually have an unencapsulated one in the application. 

>> It looks like quite a few todo's and hacks are in there as well.
> 
> Yep. It got to this mostly workable state some time ago and other things
> have taken precedence since.
> 
>> I'll try to help as much as I can, and hopefully we can get this in
>> good shape to merge in to Dan's codebase. Are you going to have any
>> time to work on this?
> 
> Yes. I really want to get some conversion constraints in before OLS.
> Things like REL and NOFORN don't go together. An interface to export
> which bits are 'inverse' would be very handy within our applications
> code. The semanage translation code is broken/obsoleted by these changes
> too.
> 

What about semanage? Is it doing translations without calling the translation interfaces that talk to the server?


--
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: releasibility in mcstransd

[Joe Nall]

On Jun 20, 2008, at 1:26 PM, Joshua Brindle wrote:

> What about semanage? Is it doing translations without calling the  
> translation interfaces that talk to the server?

semanage translation munges the setrans.conf in an incompatible way.

It assumes a 1 to 1 translation model. It could possibly be made to  
work with some file name conventions.

joe


--
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: releasibility in mcstransd

[Joe Nall]

On Jun 20, 2008, at 1:26 PM, Joshua Brindle wrote:

> Joe Nall wrote:
>>
>> On Jun 20, 2008, at 10:37 AM, Joshua Brindle wrote:
>>
>>> Joe Nall wrote:
>>>>
>>>> ...
>>>> Attached is a source rpm based on the mcstransd we are using  
>>>> internally.
>>>> It can translate ranges that look like:
>>>>
>>> Thanks for this. I started looking at the diff and it is pretty
>>> significant, it might take me a while to get through it all. One  
>>> thing
>>> I noticed immediately is that you are duplicating interfaces present
>>> in libsepol such as mls_level_to_string, mls_level_from_string and
>>> importing private headers from libsepol.
>>
>> IIRC, the functions were not exported. I'm more than willing to drop
>> those routines and use libsepol.
>>
>>> I don't think we want to proceed this way. If possible we should be
>>> using the libsepol interfaces and encapsulating the private types as
>>> necessary.
>>
>> I agree
>>
>
> Stephen: What do you think we should do about this? We've talked  
> about losing some of the encapsulation in libsepol but that was  
> related to policydb. Should we just export the mls types for now and  
> use those or continue by making them opaque? Since this mcstrans  
> does alot of operations on them it might make making them opaque  
> difficult. We could probably move alot of the functionality out of  
> mcstrans and in to libsepol but that would be coupling our libs to  
> this particular translation scheme which I thought we were trying to  
> avoid?
>
>>> The ebitmap operations can certainly be put in libsepol but  
>>> shouldn't
>>> be called directly the way they are.
>>
>> I like to putting the additional ebitmap functions in libsepol. I was
>> hoping Stephen would make them faster too :) I don't understand the
>> 'shouldn't be called directly the way they are' comment.
>>
>
> ebitmaps aren't exported so you'd never actually have an  
> unencapsulated one in the application.

FWIW, we do a fair amount of application level category bit twiddling  
beyond what mcstrans does. Having interfaces that allow access to the  
bits is a good thing. Our needs may not be representative :)

joe


--
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: releasibility in mcstransd

[Daniel J Walsh]

Joe Nall wrote:
> 
> On Jun 20, 2008, at 1:26 PM, Joshua Brindle wrote:
> 
>> What about semanage? Is it doing translations without calling the
>> translation interfaces that talk to the server?
> 
> semanage translation munges the setrans.conf in an incompatible way.
> 
> It assumes a 1 to 1 translation model. It could possibly be made to work
> with some file name conventions.
> 
> joe
> 
> 
> -- 
> 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.
We can change the semanage interface or drop it if this is too complicated.

--
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: releasibility in mcstransd

[Joshua Brindle]

Daniel J Walsh wrote:
> Joe Nall wrote:
>> On Jun 20, 2008, at 1:26 PM, Joshua Brindle wrote:
>>
>>> What about semanage? Is it doing translations without calling the
>>> translation interfaces that talk to the server?
>> semanage translation munges the setrans.conf in an incompatible way.
>>
>> It assumes a 1 to 1 translation model. It could possibly be made to work
>> with some file name conventions.
>>
>> joe
>>
>>
>> -- 
>> 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.
> We can change the semanage interface or drop it if this is too complicated.
> 

I think for the time being we should not be importing the updated mcstrans into fedora. There are still some unanswered questions about the implementation. We are talking about some of these offline.


--
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: releasibility in mcstransd

[Paul Moore]

On Friday 27 June 2008 9:42:48 am Joshua Brindle wrote:
> I think for the time being we should not be importing the updated
> mcstrans into fedora. There are still some unanswered questions about
> the implementation. We are talking about some of these offline.

Any particular reason why the discussion isn't online?  Granted I'm not 
sure I would have much useful to contribute but I do like hearing about 
what is going on and the discussion behind the decisions ...

-- 
paul moore
linux @ hp

--
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: releasibility in mcstransd

[Joshua Brindle]

Paul Moore wrote:
> On Friday 27 June 2008 9:42:48 am Joshua Brindle wrote:
>> I think for the time being we should not be importing the updated
>> mcstrans into fedora. There are still some unanswered questions about
>> the implementation. We are talking about some of these offline.
> 
> Any particular reason why the discussion isn't online?  Granted I'm not 
> sure I would have much useful to contribute but I do like hearing about 
> what is going on and the discussion behind the decisions ...
> 

Oops, I misspoke. The unanswered questions were on list, how to deal with the use of private libsepol types, duplicated functions and missing ebitmap functionality in the library. 


--
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: releasibility in mcstransd

[Joe Nall]

On Jun 27, 2008, at 1:56 PM, Joshua Brindle wrote:

> Paul Moore wrote:
>> On Friday 27 June 2008 9:42:48 am Joshua Brindle wrote:
>>> I think for the time being we should not be importing the updated
>>> mcstrans into fedora. There are still some unanswered questions  
>>> about
>>> the implementation. We are talking about some of these offline.
>>
>> Any particular reason why the discussion isn't online?  Granted I'm  
>> not
>> sure I would have much useful to contribute but I do like hearing  
>> about
>> what is going on and the discussion behind the decisions ...
>>
>
> Oops, I misspoke. The unanswered questions were on list, how to deal  
> with the use of private libsepol types, duplicated functions and  
> missing ebitmap functionality in the library.

Any progress or thoughts on this?

joe

--
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: releasibility in mcstransd

[Stephen Smalley]

On Tue, 2008-07-08 at 10:54 -0500, Joe Nall wrote:
> On Jun 27, 2008, at 1:56 PM, Joshua Brindle wrote:
> 
> > Paul Moore wrote:
> >> On Friday 27 June 2008 9:42:48 am Joshua Brindle wrote:
> >>> I think for the time being we should not be importing the updated
> >>> mcstrans into fedora. There are still some unanswered questions  
> >>> about
> >>> the implementation. We are talking about some of these offline.
> >>
> >> Any particular reason why the discussion isn't online?  Granted I'm  
> >> not
> >> sure I would have much useful to contribute but I do like hearing  
> >> about
> >> what is going on and the discussion behind the decisions ...
> >>
> >
> > Oops, I misspoke. The unanswered questions were on list, how to deal  
> > with the use of private libsepol types, duplicated functions and  
> > missing ebitmap functionality in the library.
> 
> Any progress or thoughts on this?

I think the best way to proceed would likely be to start proposing what
set of interfaces you need from libsepol in order to implement your
functionality w/o binding mcstrans too tightly to the internal policy
representation (such that if we later change the policy internal
representation of a mls range/level, it doesn't break mcstrans at all).
Patches demonstrating such interfaces would be fine too.  We may need
some intermediate data structures that are a little bit abstracted from
the raw policy structures.

-- 
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: releasibility in mcstransd

[Joshua Brindle]

Joe Nall wrote:
> 
> On Jun 27, 2008, at 1:56 PM, Joshua Brindle wrote:
> 
>> Paul Moore wrote:
>>> On Friday 27 June 2008 9:42:48 am Joshua Brindle wrote:
>>>> I think for the time being we should not be importing the updated
>>>> mcstrans into fedora. There are still some unanswered questions about
>>>> the implementation. We are talking about some of these offline.
>>>
>>> Any particular reason why the discussion isn't online?  Granted I'm not
>>> sure I would have much useful to contribute but I do like hearing about
>>> what is going on and the discussion behind the decisions ...
>>>
>>
>> Oops, I misspoke. The unanswered questions were on list, how to deal
>> with the use of private libsepol types, duplicated functions and
>> missing ebitmap functionality in the library.
> 
> Any progress or thoughts on this?
> 

Not over here. I do have someone trying to use the updated server so I'll hopefully hear any comments or concerns back from them. 

On the technical issues above, I don't think Steve wanted the functionality pushed into the library but without either doing that or encapsulating all these types the server will always have to be statically linked against libsepol, which I'd like to avoid. 

I'll change my mind if it comes down to this server needs more information about the level than we can reasonably give via 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.