Policy compiler issues.

Policy compiler issues.

[Bush, Daniel]

Hi all,
  I've got what is probably a fairly stupid question, but I'll ask anyway:
  I'm trying to deploy SELInux in an embedded environment. Footprint space is tight, every kilobyte counts. The environment is also fairly dynamic, the users list and assigned roles can change fairly rapidly.
  It's my understanding that whenever the users' list changes (aside from default users)in a SELinux system, that the policy files and security labels need to be re-compiled. Is there any way around that? Can a user be assigned a set of (non-default user) roles without re-compiling the security system?

  Another question: Can SELinux be compiled under uClibc? I'm not having much luck at that, and I was wondering if something special needed to be done, or if anybody had any tips.

Thanks in advance for your patience and help.

-=Dan Bush
"Peace through superior surrealism"



--
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: Policy compiler issues.

[Russell Coker]

On Thu, 20 May 2004 08:10, "Bush, Daniel" <Daniel.Bush@boeing.com> wrote:
> It's my
> understanding that whenever the users' list changes (aside from default
> users)in a SELinux system, that the policy files and security labels need
> to be re-compiled. Is there any way around that? Can a user be assigned a
> set of (non-default user) roles without re-compiling the security system?

You can add new users to the policy database or permit existing users to use 
more roles without any significant cost.  You have to build and install a new 
policydb which isn't a significant cost (but may be on embedded systems - I 
never got M4 to work on an iPaQ, and the >3M of storage required is a problem 
when you only have 32M on the system).

If you want to remove a user then you will need to relabel any files that they 
may have created.  That is usually limited to their home 
directory, /tmp, /var/tmp, and /var/run (shouldn't be a huge cost).  Removing 
roles from a user does not necessarily require relabelling any files (but may 
deny that user access to files that they had created if you don't relabel).

>   Another question: Can SELinux be compiled under uClibc? I'm not having
> much luck at that, and I was wondering if something special needed to be
> done, or if anybody had any tips.

What compile errors do you get?  It should work but AFAIK no-one has bothered 
trying to do it before.

-- 
http://apac.redhat.com/disclaimer
See above URL for disclaimer.

--
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: Policy compiler issues.

[Luke Kenneth Casson Leighton]

On Wed, May 19, 2004 at 06:10:17PM -0400, Bush, Daniel wrote:
> Hi all,

>   I've got what is probably a fairly stupid question, but I'll ask anyway:
>   I'm trying to deploy SELInux in an embedded environment. Footprint space is tight, every kilobyte counts. The environment is also fairly dynamic, the users list and assigned roles can change fairly rapidly.
>   It's my understanding that whenever the users' list changes (aside from default users)in a SELinux system, that the policy files and security labels need to be re-compiled. Is there any way around that? Can a user be assigned a set of (non-default user) roles without re-compiling the security system?
 
 hello, yes: if you look at /etc/selinux/users, you will note this:

 #
 # user_u is a generic user identity for Linux users who have no
 # SELinux user identity defined.  The modified daemons will use
 # this user identity in the security context if there is no matching
 # SELinux user identity for a Linux user.  If you do not want to
 # permit any access to such users, then remove this entry.
 #
 user user_u roles { user_r ifdef(`user_canbe_sysadm', `sysadm_r
 system_r') };


 so, if you don't want users to be able to be sysadmins, then
 edit tunable.te to exclude the user_canbe_sysadm ifdef.

 la?

 l.


--
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: Policy compiler issues.

[Stephen Smalley]

On Wed, 2004-05-19 at 18:10, Bush, Daniel wrote:
>   I'm trying to deploy SELInux in an embedded environment. Footprint
> space is tight, every kilobyte counts. The environment is also fairly
> dynamic, the users list and assigned roles can change fairly rapidly.

That seems like an odd combination - embedded but highly dynamic users
and roles?  How do you plan on distributing updates to the users list
and user-role authorizations?

>   It's my understanding that whenever the users' list changes (aside
> from default users)in a SELinux system, that the policy files and
> security labels need to be re-compiled. Is there any way around that?
> Can a user be assigned a set of (non-default user) roles without
> re-compiling the security system?

If you want the user to be recognized by SELinux as an individual user,
then you need to modify the policy (either directly patching the binary
policy or modifying the source and recompiling) and reload it.  There is
already a user_u user that is a fallback for ordinary users who do not
have a specific entry in the SELinux policy, so if you don't add the
user to the SELinux policy, he will be mapped to user_u and limited to
the roles authorized for user_u.  Direct manipulation of the binary
policy is possible, and I expect that libraries and tools for doing so
will become available; note the earlier work by Tresys on binary policy
patching that was posted to this list, plus the posting re future work
on loadable binary policy modules. 

>   Another question: Can SELinux be compiled under uClibc? I'm not
> having much luck at that, and I was wondering if something special
> needed to be done, or if anybody had any tips.

I haven't tried.  What kind of problem are you encountering?

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: Policy compiler issues.

[Bush, Daniel]

First and foremost: Thank you all for your help. I REALLY appreciate it. 
That said:

>>   I'm trying to deploy SELInux in an embedded environment. Footprint 
>> space is tight, every kilobyte counts. The environment is also fairly 
>> dynamic, the users list and assigned roles can change fairly rapidly.
>
>That seems like an odd combination - embedded but highly dynamic users and roles?  
    Yes, it's an odd combination, but _is_ the case. 

>How do you plan on distributing updates to the users list and user-role authorizations?
   That's another part of the problem... We have a server/management mechanisim planned, but it's a Win2k environment (Yeah, yeah, I know. Wasn't my decision...) I figure we can deploy the compilers on a suitably modified CygWin, mount either the CygWin or the SELinux device as an NFS device on the other, and get the necessary functionality that way. We're still working on that.
   As it stands the whole system needs to weigh in at less than about 64M with smaller being MUCH better (32M would be ideal.) So you can see, there's not much room for a full compiler/linker suite.

>> Can a user be assigned a set of (non-default user) roles without 
>> re-compiling the security system?

>If you want the user to be recognized by SELinux as an individual user, then you need to >modify the policy (either directly patching the binary policy or modifying the source and >recompiling) and reload it.  There is already a user_u user that is a fallback for 
>ordinary users who do not have a specific entry in the SELinux policy, so if you don't 
>add the user to the SELinux policy, he will be mapped to user_u and limited to the roles >authorized for user_u. 
    "user_u" isn't really the problem. The other, higher orders are. The specification calls for a couple of new user classes (I'm pretty sure I can institute those.) and those  classes have a forseeable need to have their membership lists changed in the field. If we need to re-compile the policy when that happens, this presents a problem.

> Direct manipulation of the binary policy is possible, and I expect that libraries and 
>tools for doing so will become available; note the earlier work by Tresys on binary 
>policy patching that was posted to this list, plus the posting re future work on loadable >binary policy modules. 

This sounds promising... Could you please direct me to the date range of the messages you're referring to?

>>   Can SELinux be compiled under uClibc? 
>I haven't tried.  What kind of problem are you encountering?
   I just wanted to know if it was definitely known Impossible before I went any further. I've just made a couple of wild stabs at it, and it could be things in my environment that are mucking up the works. (It's definitely not ready for prime-time yet...) Since I seem to be cutting new trail here, I'll keep everybody posted on my progress. 

-=Dan Bush
"Peace through superior surrealism"



--
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: Policy compiler issues.

[Stephen Smalley]

On Thu, 2004-05-20 at 11:54, Bush, Daniel wrote:
> >How do you plan on distributing updates to the users list and user-role authorizations?
>    As it stands the whole system needs to weigh in at less than about
> 64M with smaller being MUCH better (32M would be ideal.) So you can
> see, there's not much room for a full compiler/linker suite.

Just to clarify, we aren't talking about a full compiler/linker suite. 
The policy compiler is just a specialized compiler for the policy
language.  And you can always recompile the policy on a "policy build
machine" and push the new binary policy to all of your embedded systems
via some mechanism, so you really only need load_policy on the embedded
systems.  load_policy is a trivial program; just opens and mmap's the
binary policy file and writes it to /selinux/load to feed it to the
kernel.

$ size /usr/sbin/load_policy
   text    data     bss     dec     hex filename
   2739     316       0    3055     bef /usr/sbin/load_policy

>     "user_u" isn't really the problem. The other, higher orders are.
> The specification calls for a couple of new user classes (I'm pretty
> sure I can institute those.) and those  classes have a forseeable need
> to have their membership lists changed in the field. If we need to
> re-compile the policy when that happens, this presents a problem.

If you set up an infrastructure that lets you rebuild policy on a
"policy build machine" and then push out the binary policy to all of
your embedded systems upon user database updates, I'm not sure that this
is a real issue.  

The alternative is to implement support for generic user identity
mapping in libselinux's get_ordered_context_list function beyond the
simple user_u support that exists today, define a set of generic user
identities one per role (staff_u, sysadm_u, etc) that are authorized for
that role, and have libselinux map all real users to one of these
generic user identities based on some other criteria (e.g. is the real
user in a particular group in the NIS map?).  That pushes responsibility
for enforcing user-role restrictions up into libselinux and ultimately
to your user database server, so you obviously need to provide
appropriate protection there.

> This sounds promising... Could you please direct me to the date range of the messages you're referring to?

http://marc.theaimsgroup.com/?l=selinux&m=106453351114046&w=2
http://marc.theaimsgroup.com/?l=selinux&m=105459714906101&w=2

The binary policy patch tools are out-of-date, and should be obsoleted
by newer work going on at Tresys to support direct manipulation of
binary policies.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: Policy compiler issues.

[Frank Mayer]

Stephen Smalley wrote:
> 
>> This sounds promising... Could you please direct me to the
>> date range of the messages you're referring to?
> 
> http://marc.theaimsgroup.com/?l=selinux&m=106453351114046&w=2
> http://marc.theaimsgroup.com/?l=selinux&m=105459714906101&w=2
> 
> The binary policy patch tools are out-of-date, and should be obsoleted
> by newer work going on at Tresys to support direct manipulation of
> binary policies.

Steve is correct, the binary patch tool was not maintained, and if I recall
correctly I don't think it supported changing users.  One could certainly hack
together something using that code to work temporarily.

The binary module work Steve indicate is probably a couple of months from
initial release, and will take some time to work out bugs and integration
issues.  Once complete this should make dynamic policy changes easier; for
example we will change our seuser tool to use it so that policy sources are not
needed, nor policy homogeneity across all systems.

Frank


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