Now that SELinux supports booleans should we replace tunables with booleans?

Now that SELinux supports booleans should we replace tunables with booleans?

[Daniel J Walsh]

Ideas?

Dan

--
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Chris PeBenito]

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

On Tue, 2004-04-13 at 08:59, Daniel J Walsh wrote:
> Ideas?
> 
> Dan

I've been thinking about this for a while.  It seems like a good idea
eventually, but the problem is with the policy v15 kernels floating
around still.  The bools get dropped, so you lose the tuning.  If
checkpolicy is modified to include the bool if the condition is met,
based on the initial setting, for v15 policy, then it could be ok.  For
example:

bool foo true;
bool bar false;
if( foo ) {
allow a_t b_t:file getattr;
}
if( bar ) {
allow c_t b_t:file getattr;
}

So, the first allow would be included, but not the second in a v15
policy.  I think I remember Russell talking about this, or something
similar.

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer,
Hardened Gentoo Linux
Embedded Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Now that SELinux supports booleans should we replace tunables with booleans?

[Tom Mitchell]

On Tue, Apr 13, 2004 at 09:59:42AM -0400, Daniel J Walsh wrote:

> Ideas?

The fewer decisions the kernel needs to make the better.  i.e. The
more decisions and analysis that can be make in advance of loading
policy the better.


-- 
	T o m  M i t c h e l l 
	/dev/null the ultimate in secure storage.

--
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Russell Coker]

On Tue, 13 Apr 2004 23:59, Daniel J Walsh <dwalsh@redhat.com> wrote:
> Ideas?

For most items in tunable.te they won't be changed often or for small reasons.  
In some cases changing tunable.te will require application restart (or system 
reboot) to fully take affect.

The aim of booleans is for things that are designed to be transient (EG secure 
levels).

Also if we use booleans for tunables we need to have boolean support for role 
and domain transitions (currently not implemented), and a mechanism for 
preserving boolean values across a reboot.

I think it's best to continue with tunables the way they are.

-- 
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Karl MacMillan]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
> Behalf Of Russell Coker
> Sent: Tuesday, April 13, 2004 7:17 PM
> To: Daniel J Walsh
> Cc: SELinux
> Subject: Re: Now that SELinux supports booleans should we replace tunables
> with booleans?
> 
> On Tue, 13 Apr 2004 23:59, Daniel J Walsh <dwalsh@redhat.com> wrote:
> > Ideas?
> 
> For most items in tunable.te they won't be changed often or for small
> reasons.
> In some cases changing tunable.te will require application restart (or
> system
> reboot) to fully take affect.
> 

Why is a reboot required?

> The aim of booleans is for things that are designed to be transient (EG
> secure
> levels).
> 

I don't agree completely with this. Booleans allow well defined policy
changes to be made by domains without policy compilation and reloading
privileges. In order to use the tunables, a user/domain must have full
access to change anything about the policy. With the booleans a user can be
authorized to change a portion of the policy in a specific way without any
other policy privileges. This seems like an important advantage to me.

> Also if we use booleans for tunables we need to have boolean support for
> role
> and domain transitions (currently not implemented), and a mechanism for
> preserving boolean values across a reboot.
> 

There is full support for type transition rules - the current Boolean
example (ping.te) in the NSA policy uses the domain_auto_trans macro within
a conditional block.

It is true that there isn't support for role statements in conditional
blocks, but it is not clear that authorizing a role for a type represents is
security risk if there are no rules that allow that role to reach the type
(again, see the ping.te example - user_r is authorized for ping_t but can
only reach it if user_ping is true). Hopefully role and role transition
statements will be supported in conditional statements soon, but it doesn't
seem like a large reason not to use the booleans for now.

As far as preserving boolean values, this doesn't seem any different from
other runtime kernel values and there are mechanism that can be easily
extended to handle this.

Karl

> I think it's best to continue with tunables the way they are.
> 

Karl MacMillan
Tresys Technology
http://www.tresys.com
(410)290-1411 ext 134

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


--
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Karl MacMillan]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
> Behalf Of Tom Mitchell
> Sent: Tuesday, April 13, 2004 1:54 PM
> To: SELinux
> Subject: Re: Now that SELinux supports booleans should we replace tunables
> with booleans?
> 
> On Tue, Apr 13, 2004 at 09:59:42AM -0400, Daniel J Walsh wrote:
> 
> > Ideas?
> 
> The fewer decisions the kernel needs to make the better.  i.e. The
> more decisions and analysis that can be make in advance of loading
> policy the better.
> 

I'm not certain this is the case. Booleans allow for fine-grained control
over policy changes by domains without full policy privileges (see my other
recent mail in this thread for more on this). This makes it easier to
analyze a policy ahead of time to make certain that it meats your security
goals in all configurations.

If you are concerned about performance, I don't think that is a problem
either. The conditional support adds minimal overhead that is probably taken
care of by the avc cache anyway.

Karl

Karl MacMillan
Tresys Technology
http://www.tresys.com
(410)290-1411 ext 134

> 
> --
> 	T o m  M i t c h e l l
> 	/dev/null the ultimate in secure storage.
> 
> --
> 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.


--
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Stephen Smalley]

On Wed, 2004-04-14 at 09:11, Karl MacMillan wrote:
> As far as preserving boolean values, this doesn't seem any different from
> other runtime kernel values and there are mechanism that can be easily
> extended to handle this.

So you are suggesting something akin to /etc/sysctl.conf for boolean
values and running something akin to sysctl -p from /etc/rc.d/rc.sysinit
to set the boolean value during initialization?

-- 
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Russell Coker]

On Wed, 14 Apr 2004 23:11, "Karl MacMillan" <kmacmillan@tresys.com> wrote:
> > For most items in tunable.te they won't be changed often or for small
> > reasons.
> > In some cases changing tunable.te will require application restart (or
> > system
> > reboot) to fully take affect.
>
> Why is a reboot required?

If we have a tunable option to determine which domain processes run in (such 
as single_userdomain) or a tunable that determines the identity that daemons 
get (such as direct_sysadm_daemon) then restarting processes is necessary.  
Some people find it difficult to do this successfully and find it easier to 
do a reboot.

> > The aim of booleans is for things that are designed to be transient (EG
> > secure
> > levels).
>
> I don't agree completely with this. Booleans allow well defined policy
> changes to be made by domains without policy compilation and reloading
> privileges. In order to use the tunables, a user/domain must have full
> access to change anything about the policy. With the booleans a user can be
> authorized to change a portion of the policy in a specific way without any
> other policy privileges. This seems like an important advantage to me.

The advantages of booleans are clear IMHO.  But they don't seem applicable to 
something that will be set at install time on a system that is capable of 
building a policy.  Maybe for an iPaQ booleans for tunable options would be 
good.  For a desktop or server they seem to offer less benefits.

Finally, for booleans both options have to be in the policydb and in the 
kernel at run-time.  For tunable.te they aren't, and can significantly reduce 
the policy size.

-- 
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: Now that SELinux supports booleans should we replace tunableswith booleans?

[Karl MacMillan]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@epoch.ncsc.mil]
> Sent: Wednesday, April 14, 2004 9:30 AM
> To: Karl MacMillan
> Cc: Russell Coker; 'Daniel J Walsh'; 'SELinux'; 'Selinux Dev'
> Subject: RE: Now that SELinux supports booleans should we replace
> tunableswith booleans?
> 
> On Wed, 2004-04-14 at 09:11, Karl MacMillan wrote:
> > As far as preserving boolean values, this doesn't seem any different
> from
> > other runtime kernel values and there are mechanism that can be easily
> > extended to handle this.
> 
> So you are suggesting something akin to /etc/sysctl.conf for boolean
> values and running something akin to sysctl -p from /etc/rc.d/rc.sysinit
> to set the boolean value during initialization?
> 

Sure - init should have the privileges to do this. The only detail is that
this should be done before any daemons are started - is rc.sysinit run early
enough?

Karl

Karl MacMillan
Tresys Technology
http://www.tresys.com
(410)290-1411 ext 134

> --
> 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: Now that SELinux supports booleans should we replace tunables with booleans?

[Karl MacMillan]

Karl MacMillan
Tresys Technology
http://www.tresys.com
(410)290-1411 ext 134 

> -----Original Message-----
> From: Russell Coker [mailto:russell@coker.com.au]
> > Why is a reboot required?
> 
> If we have a tunable option to determine which domain processes run in
> (such
> as single_userdomain) or a tunable that determines the identity that
> daemons
> get (such as direct_sysadm_daemon) then restarting processes is necessary.
> Some people find it difficult to do this successfully and find it easier
> to
> do a reboot.
> 

Sure.

> 
> The advantages of booleans are clear IMHO.  But they don't seem applicable
> to
> something that will be set at install time on a system that is capable of
> building a policy.  Maybe for an iPaQ booleans for tunable options would
> be
> good.  For a desktop or server they seem to offer less benefits.
> 

If it is only set at install time, then maybe tunables.te makes sense.

> Finally, for booleans both options have to be in the policydb and in the
> kernel at run-time.  For tunable.te they aren't, and can significantly
> reduce
> the policy size.
> 

Again, if this is truly only set at install time this might be true. I'm not
convinced that these things will only be set at install time, though, and in
that case I think it might make sense to use the booleans. Also, the size
overhead may be preferable to requiring administrators to build policy from
source.

Karl

> --
> 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: Now that SELinux supports booleans should we replace tunableswith booleans?

[Russell Coker]

On Thu, 15 Apr 2004 00:10, "Karl MacMillan" <kmacmillan@tresys.com> wrote:
> Sure - init should have the privileges to do this. The only detail is that
> this should be done before any daemons are started - is rc.sysinit run
> early enough?

rc.sysinit is run directly from init before it does anything else.  Maybe we 
could fsck the root fs before changing booleans, but that should be OK.

If you have booleans affecting the core operations of init and scripts it 
launches then you are just asking for trouble.

The only thing which affects init_t or initrc_t in any significant way which 
could be a boolean (IMHO) is the ability of those domains to change booleans.  
If we have initrc_t changing booleans on startup then one option is having it 
remove it's own access to change the booleans after it's done so.

-- 
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Russell Coker]

On Wed, 14 Apr 2004 23:16, "Karl MacMillan" <kmacmillan@tresys.com> wrote:
> I'm not certain this is the case. Booleans allow for fine-grained control
> over policy changes by domains without full policy privileges (see my other
> recent mail in this thread for more on this). This makes it easier to
> analyze a policy ahead of time to make certain that it meats your security
> goals in all configurations.

I agree that using tunable.te instead of booleans does not make it any easier 
for us (as distribution vendors) to analyse the complete policy.  However I 
believe that it does make it significantly easier for users to analyse the 
configurations that they will use.  On my machines I run significantly 
tighter security settings than we ship for Fedora Core (more like what we 
will probably ship for RHEL 4).  So to analyse the policy for my own personal 
use I would not want to consider options such as ssh_sysadm_login, 
xdm_sysadm_login, nfs_home_dirs, and allow_user_direct_mouse as they will 
never be enabled on any machines which matter to me.

We currently have 21 tunable.te options, most of them are options to turn 
things off, so you can analyse the policy with them turned on and if the 
results of that analysis are acceptable then you can be sure that turning 
those options off will only make things more secure.

However some options are either/or options.  Such as whether to run sshd from 
inetd or as a daemon.  In these cases both options have different security 
implications.  I guess you could analyse the union of the operations that are 
granted and analyse that (which would be OK in this example).  But for other 
tunable options in future we may not be able to work this way.

> If you are concerned about performance, I don't think that is a problem
> either. The conditional support adds minimal overhead that is probably
> taken care of by the avc cache anyway.

I think that the issue with performance is kernel memory use.  Currently for 
FC2T2 we have 7M policydb files which roughly equates to 7M of kernel memory 
reserved, which has a huge impact on older hardware!  Most of this is due to 
compiling in support for every .te file.

For a typical machine compiling only the .te files that we need should get 
this down to around 2M.  So obviously for space the correct selection of .te 
files is a much more significant issue than booleans.  However such selection 
of .te files requires a full environment for building policy on each machine 
(which removes one of the advantages you stated for using booleans instead of 
tunables).  As configuration of policy features in ways other than removal of 
unwanted .te files becomes more popular, the volume of policy (and therefore 
size of policydb) will depend much more on such things.  I expect that in the 
not too distant future we will have a factor of 2-3 in policydb size 
determined by tunables.  If this is all done in booleans then there will be 
some significant amounts of wasted space.

-- 
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Karl MacMillan]

> -----Original Message-----
> From: Russell Coker [mailto:russell@coker.com.au]
> I think that the issue with performance is kernel memory use.  Currently
> for
> FC2T2 we have 7M policydb files which roughly equates to 7M of kernel
> memory
> reserved, which has a huge impact on older hardware!  Most of this is due
> to
> compiling in support for every .te file.
> 
> For a typical machine compiling only the .te files that we need should get
> this down to around 2M.  So obviously for space the correct selection of
> .te
> files is a much more significant issue than booleans.  However such
> selection
> of .te files requires a full environment for building policy on each
> machine
> (which removes one of the advantages you stated for using booleans instead
> of
> tunables).  As configuration of policy features in ways other than removal
> of
> unwanted .te files becomes more popular, the volume of policy (and
> therefore
> size of policydb) will depend much more on such things.  I expect that in
> the
> not too distant future we will have a factor of 2-3 in policydb size
> determined by tunables.  If this is all done in booleans then there will
> be
> some significant amounts of wasted space.
> 

This definitely is a problem, especially since this kernel memory is not
swappable. If this amount of policy is controlled by the tunables (much more
than I thought) then I agree that it is best left as tunables for now.

Karl


Karl MacMillan
Tresys Technology
http://www.tresys.com
(410)290-1411 ext 134

> --
> 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: Now that SELinux supports booleans should we replace tunables with booleans?

[Valdis.Kletnieks]

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

On Thu, 15 Apr 2004 02:19:27 +1000, Russell Coker said:

> For a typical machine compiling only the .te files that we need should get 
> this down to around 2M.  So obviously for space the correct selection of .te 
> files is a much more significant issue than booleans.  However such selection 
> of .te files requires a full environment for building policy on each machine

Would a return to the policy/*.te and policy/unused/*.te split, with a
really silly shell script that does the moral equiv of:

for i in unused/*.te; do rpm -qf $i && mv $i .; done

(i.e. if the program is installed, move the .te out of unused)

be a short-term direction we want to look at?  Longer term,
a similar "tweak the tunables to match the installed software" program
would probably be needed....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Now that SELinux supports booleans should we replace tunables with booleans?

[James Morris]

On Thu, 15 Apr 2004, Russell Coker wrote:

> I think that the issue with performance is kernel memory use.  Currently for 
> FC2T2 we have 7M policydb files which roughly equates to 7M of kernel memory 
> reserved, which has a huge impact on older hardware!  Most of this is due to 
> compiling in support for every .te file.

I think it's worse than this.  It looks like we're using about 40 bytes of
kernel memory for each rule, and with almost 300,000 rules, it's more like
12MB (for i386).

Making better use of kernel memory is on my todo list.


- James
-- 
James Morris
<jmorris@redhat.com>



--
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: Now that SELinux supports booleans should we replace tunables with booleans?

[James Morris]

On Wed, 14 Apr 2004, James Morris wrote:

> I think it's worse than this.  It looks like we're using about 40 bytes of
> kernel memory for each rule, and with almost 300,000 rules, it's more like
> 12MB (for i386).

Actually it's 32 bytes per rule (I had slab debugging enabled, which uses
a bit more), but still a lot.  And on 64-bit, it's using twice as much
memory.

- James
-- 
James Morris
<jmorris@redhat.com>



--
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Russell Coker]

On Thu, 15 Apr 2004 12:29, Daniel J Walsh <dwalsh@redhat.com> wrote:
> I would prefer not to use unused at all, but some macro version to
> indicate whether to include a te
> file or not.  Moving files around on the fly is not a great solution.

The problem is that in some cases there will be several rpms which may require 
a particular .te file.  One solution is to have a directory of .te files 
which can be copied in if any of the candidate rpms is installed.  Another is 
to have a small rpm contain the .te file in question and then have all the 
rpms that need that policy depend on the .te file.

-- 
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Valdis.Kletnieks]

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

On Wed, 14 Apr 2004 22:29:44 EDT, you said:

> >really silly shell script that does the moral equiv of:
> >
> >for i in unused/*.te; do rpm -qf $i && mv $i .; done
> >  
> >
> There is not a 1-1 relationship between rpm names and policy names.

Right.  That's why I said "the moral equivalent of".  Any other
equivalent means of trimming out .te files for software that isn't even
installed would work too.

I liked Russell's suggestion that we have a separate rpm that contains
the .te for the package - appropriate %postinstall scripting magic
would make all the policy rebuilding/reloading and file labelling happen
when you installed the package....

> I would prefer not to use unused at all, but some macro version to 
> indicate whether to include a te
> file or not.  Moving files around on the fly is not a great solution.

Wrapping all of them in m4 ifdef() blocks and a front end that sets
control variables would be OK too.  If m4 can deal with Sendmail's
.mc/.cf file wierdness, it can do this... :)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

RE: Now that SELinux supports booleans should we replace tunables with booleans?

[Karl MacMillan]

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

> > I think that the issue with performance is kernel memory use.  Currently
> for
> > FC2T2 we have 7M policydb files which roughly equates to 7M of kernel
> memory
> > reserved, which has a huge impact on older hardware!  Most of this is
> due to
> > compiling in support for every .te file.
> 
> I think it's worse than this.  It looks like we're using about 40 bytes of
> kernel memory for each rule, and with almost 300,000 rules, it's more like
> 12MB (for i386).
> 
> Making better use of kernel memory is on my todo list.
> 

I dug up two simple patches that I did a while back for the conditional
policy work that makes the avtab size configurable. It won't help much, but
it allows for a smaller conditional avtab on the assumption that there will
be fewer conditional rules. I also had a patch to make the hashing perform
slightly better which helped when using a smaller number of buckets, but I
can't find that. These patches are against on older checkpolicy and linux
2.6.1, but they are trivial enough to port if you think they are useful.

Karl

Karl MacMillan
Tresys Technology
http://www.tresys.com
(410)290-1411 ext 134

> 
> - James
> --
> James Morris
> <jmorris@redhat.com>
> 
> 
> 
> --
> 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.

[-- Attachment #2: conditional-avtab-selinux-usr-1-15-2004.patch --]
[-- Type: application/octet-stream, Size: 5150 bytes --]

diff -Nru a/selinux-usr/checkpolicy/avtab.c b/selinux-usr/checkpolicy/avtab.c
--- a/selinux-usr/checkpolicy/avtab.c	Thu Jan 15 16:22:45 2004
+++ b/selinux-usr/checkpolicy/avtab.c	Thu Jan 15 16:22:45 2004
@@ -20,11 +20,11 @@
 #include "avtab.h"
 #include "policydb.h"
 
-#define AVTAB_HASH(keyp) \
+#define AVTAB_HASH(keyp, mask) \
 ((keyp->target_class + \
  (keyp->target_type << 2) + \
  (keyp->source_type << 9)) & \
- AVTAB_HASH_MASK)
+ mask)
 
 static avtab_ptr_t 
    avtab_insert_node(avtab_t *h, int hvalue, avtab_ptr_t prev, avtab_ptr_t cur, avtab_key_t *key, avtab_datum_t *datum)
@@ -58,7 +58,7 @@
 	if (!h)
 		return -ENOMEM;
 
-	hvalue = AVTAB_HASH(key);
+	hvalue = AVTAB_HASH(key, h->mask);
 	for (prev = NULL, cur = h->htable[hvalue];
 	     cur;
 	     prev = cur, cur = cur->next) {
@@ -97,7 +97,7 @@
 
 	if (!h)
 		return NULL;
-	hvalue = AVTAB_HASH(key);
+	hvalue = AVTAB_HASH(key, h->mask);
 	for (prev = NULL, cur = h->htable[hvalue];
 	     cur;
 	     prev = cur, cur = cur->next) {
@@ -152,7 +152,7 @@
 	if (!h)
 		return NULL;
 
-	hvalue = AVTAB_HASH(key);
+	hvalue = AVTAB_HASH(key, h->mask);
 	for (cur = h->htable[hvalue]; cur; cur = cur->next) {
 		if (key->source_type == cur->key.source_type && 
 		    key->target_type == cur->key.target_type &&
@@ -186,7 +186,7 @@
 	if (!h)
 		return NULL;
 
-	hvalue = AVTAB_HASH(key);
+	hvalue = AVTAB_HASH(key, h->mask);
 	for (cur = h->htable[hvalue]; cur; cur = cur->next) {
 		if (key->source_type == cur->key.source_type && 
 		    key->target_type == cur->key.target_type &&
@@ -244,7 +244,7 @@
 	if (!h)
 		return;
 
-	for (i = 0; i < AVTAB_SIZE; i++) {
+	for (i = 0; i < h->size; i++) {
 		cur = h->htable[i];
 		while (cur != NULL) {
 			temp = cur;
@@ -270,7 +270,7 @@
 	if (!h)
 		return 0;
 
-	for (i = 0; i < AVTAB_SIZE; i++) {
+	for (i = 0; i < h->size; i++) {
 		cur = h->htable[i];
 		while (cur != NULL) {
 			ret = apply(&cur->key, &cur->datum, args);
@@ -283,14 +283,17 @@
 }
 
 
-int avtab_init(avtab_t * h)
+int avtab_init(avtab_t * h, __u32 bits)
 {
 	int i;
 
-	h->htable = kmalloc(sizeof(avtab_ptr_t)*AVTAB_SIZE,GFP_KERNEL);
+	h->size = 1 << bits;
+	h->mask = h->size - 1;
+
+	h->htable = kmalloc(sizeof(avtab_ptr_t)*h->size,GFP_KERNEL);
 	if (!h->htable)
 		return -1;
-	for (i = 0; i < AVTAB_SIZE; i++)
+	for (i = 0; i < h->size; i++)
 		h->htable[i] = (avtab_ptr_t) NULL;
 	h->nel = 0;
 	return 0;
@@ -305,7 +308,7 @@
 
 	slots_used = 0;
 	max_chain_len = 0;
-	for (i = 0; i < AVTAB_SIZE; i++) {
+	for (i = 0; i < h->size; i++) {
 		cur = h->htable[i];
 		if (cur) {
 			slots_used++;
@@ -321,7 +324,7 @@
 	}
 
 	printk("%s:  %d entries and %d/%d buckets used, longest chain length %d\n",
-	       tag, h->nel, slots_used, AVTAB_SIZE, max_chain_len);
+	       tag, h->nel, slots_used, h->size, max_chain_len);
 }
 
 int avtab_read_item(void *fp, avtab_datum_t *avdatum, avtab_key_t *avkey)
diff -Nru a/selinux-usr/checkpolicy/avtab.h b/selinux-usr/checkpolicy/avtab.h
--- a/selinux-usr/checkpolicy/avtab.h	Thu Jan 15 16:22:45 2004
+++ b/selinux-usr/checkpolicy/avtab.h	Thu Jan 15 16:22:45 2004
@@ -61,11 +61,13 @@
 };
 
 typedef struct avtab {
+	__u32 size;
+	__u64 mask;
 	avtab_ptr_t *htable;
 	__u32 nel;	/* number of elements */
 } avtab_t;
 
-int avtab_init(avtab_t *);
+int avtab_init(avtab_t *h, __u32 bits);
 
 int avtab_insert(avtab_t * h, avtab_key_t * k, avtab_datum_t * d);
 
@@ -93,12 +95,6 @@
 avtab_ptr_t avtab_search_node(avtab_t * h, avtab_key_t * key, int specified);
 
 avtab_ptr_t avtab_search_node_next(avtab_ptr_t node, int specified);
-
-#define AVTAB_HASH_BITS 15
-#define AVTAB_HASH_BUCKETS (1 << AVTAB_HASH_BITS)
-#define AVTAB_HASH_MASK (AVTAB_HASH_BUCKETS-1)
-
-#define AVTAB_SIZE AVTAB_HASH_BUCKETS
 
 #endif	/* _AVTAB_H_ */
 
diff -Nru a/selinux-usr/checkpolicy/conditional.c b/selinux-usr/checkpolicy/conditional.c
--- a/selinux-usr/checkpolicy/conditional.c	Thu Jan 15 16:22:45 2004
+++ b/selinux-usr/checkpolicy/conditional.c	Thu Jan 15 16:22:45 2004
@@ -351,7 +351,7 @@
 {
 	p->bool_val_to_struct = NULL;
 	p->cond_list = NULL;
-	if (avtab_init(&p->te_cond_avtab))
+	if (avtab_init(&p->te_cond_avtab, 8))
 		return -1;
 
 	return 0;
diff -Nru a/selinux-usr/checkpolicy/policydb.c b/selinux-usr/checkpolicy/policydb.c
--- a/selinux-usr/checkpolicy/policydb.c	Thu Jan 15 16:22:45 2004
+++ b/selinux-usr/checkpolicy/policydb.c	Thu Jan 15 16:22:45 2004
@@ -100,7 +100,7 @@
 			goto out_free_symtab;
 	}
 
-	rc = avtab_init(&p->te_avtab);
+	rc = avtab_init(&p->te_avtab, 15);
 	if (rc)
 		goto out_free_symtab;
 
diff -Nru a/selinux-usr/checkpolicy/write.c b/selinux-usr/checkpolicy/write.c
--- a/selinux-usr/checkpolicy/write.c	Thu Jan 15 16:22:45 2004
+++ b/selinux-usr/checkpolicy/write.c	Thu Jan 15 16:22:45 2004
@@ -105,7 +105,7 @@
 	if (items != 1)
 		return -1;
 
-	for (i = 0; i < AVTAB_SIZE; i++) {
+	for (i = 0; i < a->size; i++) {
 		for (cur = a->htable[i]; cur; cur = cur->next) {
 			if (avtab_write_item(cur, fp))
 			    return -1;

[-- Attachment #3: conditional-avtab-linux-2.6-1-15-2004.patch --]
[-- Type: application/octet-stream, Size: 4885 bytes --]

diff -Nru a/linux-2.6/security/selinux/ss/avtab.c b/linux-2.6/security/selinux/ss/avtab.c
--- a/linux-2.6/security/selinux/ss/avtab.c	Thu Jan 15 16:22:31 2004
+++ b/linux-2.6/security/selinux/ss/avtab.c	Thu Jan 15 16:22:31 2004
@@ -22,11 +22,11 @@
 #include "avtab.h"
 #include "policydb.h"
 
-#define AVTAB_HASH(keyp) \
+#define AVTAB_HASH(keyp, mask) \
 ((keyp->target_class + \
  (keyp->target_type << 2) + \
  (keyp->source_type << 9)) & \
- AVTAB_HASH_MASK)
+ mask)
 
 static struct avtab_node*
 avtab_insert_node(struct avtab *h, int hvalue, struct avtab_node * prev, struct avtab_node * cur,
@@ -59,7 +59,7 @@
 	if (!h)
 		return -EINVAL;
 
-	hvalue = AVTAB_HASH(key);
+	hvalue = AVTAB_HASH(key, h->mask);
 	for (prev = NULL, cur = h->htable[hvalue];
 	     cur;
 	     prev = cur, cur = cur->next) {
@@ -98,7 +98,7 @@
 
 	if (!h)
 		return NULL;
-	hvalue = AVTAB_HASH(key);
+	hvalue = AVTAB_HASH(key, h->mask);
 	for (prev = NULL, cur = h->htable[hvalue];
 	     cur;
 	     prev = cur, cur = cur->next) {
@@ -130,7 +130,7 @@
 	if (!h)
 		return NULL;
 
-	hvalue = AVTAB_HASH(key);
+	hvalue = AVTAB_HASH(key, h->mask);
 	for (cur = h->htable[hvalue]; cur; cur = cur->next) {
 		if (key->source_type == cur->key.source_type &&
 		    key->target_type == cur->key.target_type &&
@@ -164,7 +164,7 @@
 	if (!h)
 		return NULL;
 
-	hvalue = AVTAB_HASH(key);
+	hvalue = AVTAB_HASH(key, h->mask);
 	for (cur = h->htable[hvalue]; cur; cur = cur->next) {
 		if (key->source_type == cur->key.source_type && 
 		    key->target_type == cur->key.target_type &&
@@ -221,7 +221,7 @@
 	if (!h)
 		return;
 
-	for (i = 0; i < AVTAB_SIZE; i++) {
+	for (i = 0; i < h->size; i++) {
 		cur = h->htable[i];
 		while (cur != NULL) {
 			temp = cur;
@@ -246,7 +246,7 @@
 	if (!h)
 		return 0;
 
-	for (i = 0; i < AVTAB_SIZE; i++) {
+	for (i = 0; i < h->size; i++) {
 		cur = h->htable[i];
 		while (cur != NULL) {
 			ret = apply(&cur->key, &cur->datum, args);
@@ -258,14 +258,17 @@
 	return 0;
 }
 
-int avtab_init(struct avtab *h)
+int avtab_init(struct avtab *h, u32 bits)
 {
 	int i;
 
-	h->htable = vmalloc(sizeof(*(h->htable)) * AVTAB_SIZE);
+	h->size = 1 << bits;
+	h->mask = h->size - 1;
+
+	h->htable = vmalloc(sizeof(*(h->htable)) * h->size);
 	if (!h->htable)
 		return -ENOMEM;
-	for (i = 0; i < AVTAB_SIZE; i++)
+	for (i = 0; i < h->size; i++)
 		h->htable[i] = NULL;
 	h->nel = 0;
 	return 0;
@@ -278,7 +281,7 @@
 
 	slots_used = 0;
 	max_chain_len = 0;
-	for (i = 0; i < AVTAB_SIZE; i++) {
+	for (i = 0; i < h->size; i++) {
 		cur = h->htable[i];
 		if (cur) {
 			slots_used++;
@@ -294,7 +297,7 @@
 	}
 
 	printk(KERN_INFO "%s:  %d entries and %d/%d buckets used, longest "
-	       "chain length %d\n", tag, h->nel, slots_used, AVTAB_SIZE,
+	       "chain length %d\n", tag, h->nel, slots_used, h->size,
 	       max_chain_len);
 }
 
diff -Nru a/linux-2.6/security/selinux/ss/avtab.h b/linux-2.6/security/selinux/ss/avtab.h
--- a/linux-2.6/security/selinux/ss/avtab.h	Thu Jan 15 16:22:31 2004
+++ b/linux-2.6/security/selinux/ss/avtab.h	Thu Jan 15 16:22:31 2004
@@ -53,11 +53,13 @@
 };
 
 struct avtab {
+	u32 size;
+	u32 mask; 
 	struct avtab_node **htable;
 	u32 nel;	/* number of elements */
 };
 
-int avtab_init(struct avtab *);
+int avtab_init(struct avtab *h, u32 bits);
 int avtab_insert(struct avtab *h, struct avtab_key *k, struct avtab_datum *d);
 struct avtab_datum *avtab_search(struct avtab *h, struct avtab_key *k, int specified);
 void avtab_destroy(struct avtab *h);
@@ -77,12 +79,6 @@
 struct avtab_node *avtab_search_node(struct avtab *h, struct avtab_key *key, int specified);
 
 struct avtab_node *avtab_search_node_next(struct avtab_node *node, int specified);
-
-#define AVTAB_HASH_BITS 15
-#define AVTAB_HASH_BUCKETS (1 << AVTAB_HASH_BITS)
-#define AVTAB_HASH_MASK (AVTAB_HASH_BUCKETS-1)
-
-#define AVTAB_SIZE AVTAB_HASH_BUCKETS
 
 #endif	/* _SS_AVTAB_H_ */
 
diff -Nru a/linux-2.6/security/selinux/ss/conditional.c b/linux-2.6/security/selinux/ss/conditional.c
--- a/linux-2.6/security/selinux/ss/conditional.c	Thu Jan 15 16:22:31 2004
+++ b/linux-2.6/security/selinux/ss/conditional.c	Thu Jan 15 16:22:31 2004
@@ -122,7 +122,7 @@
 {
 	p->bool_val_to_struct = NULL;
 	p->cond_list = NULL;
-	if (avtab_init(&p->te_cond_avtab))
+	if (avtab_init(&p->te_cond_avtab, 8))
 		return -1;
 
 	return 0;
diff -Nru a/linux-2.6/security/selinux/ss/policydb.c b/linux-2.6/security/selinux/ss/policydb.c
--- a/linux-2.6/security/selinux/ss/policydb.c	Thu Jan 15 16:22:31 2004
+++ b/linux-2.6/security/selinux/ss/policydb.c	Thu Jan 15 16:22:31 2004
@@ -102,7 +102,7 @@
 			goto out_free_symtab;
 	}
 
-	rc = avtab_init(&p->te_avtab);
+	rc = avtab_init(&p->te_avtab, 15);
 	if (rc)
 		goto out_free_symtab;
 

RE: Now that SELinux supports booleans should we replace tunables with booleans?

[Stephen Smalley]

I wanted to re-open this thread of discussion regarding whether some of
the current policy compile-time tunables should be converted to runtime
policy booleans.  The policy tunables were originally introduced prior
to the merging of the conditional policy support, but conditional
support has been available in the mainline kernel since Linux 2.6.5.  I
have created some experimental policy patches converting many of the
base tunables from tunable.{tun,te} to booleans; these are presently
available in the sourceforge CVS tree and I'll include one small patch
below for reference as an example.  

Of the remaining base tunables from tunable.tun, I believe that either
they are not amenable to the use of policy booleans (i.e. affect type
declarations or role-based statements) or they would activate many
additional rules when enabled and it would thus bloat the policy to make
them runtime conditionals.  However, I'm open to reconsidering some of
the latter cases, and even to re-thinking how we approach some of the
former cases to allow us to leverage booleans to some degree.

As previously discussed, we will need a mechanism to preserve policy
boolean values across a reboot, so we will need an equivalent to
/etc/sysctl.conf for the policy booleans as part of the policy
configuration under /etc/selinux, and we will need rc.sysinit to
initialize the policy booleans accordingly as it already does for sysctl
values.  

As a minor issue, we should also reconsider the names of the boolean
utilities, as they are too generic and could easily conflict in the
future with other non-SELinux programs.  Also, Chris PeBenito posted a
toggle_bool utility a while back that would likely be useful to add.

The patch below shows an example of converting the ssh-related tunables
to policy booleans.  There are a couple of non-obvious aspects of the
patch:  1) it makes the var_run_domain() rules unconditional since type
declarations cannot be conditional, and 2) it completely removes the old
can_tcp_connect() rules, as they presently expand to nothing (due to the
lack of labeled networking), and the conditional policy grammar doesn't
presently allow empty conditional blocks.  The first issue is indicative
of a common problem when using the policy booleans, because existing
macros often combine a type declaration and rules allowing access to it
as a single unit, whereas the policy booleans can only be used to wrap
the allow rules.  If the access were deemed significant enough, we could
inline the macro and make the allow rules conditional while keeping the
type unconditional, but this doesn't seem worthwhile in this case.  The
second issue could be addressed in checkpolicy, but it seems reasonable
to just view this as a cleanup to purge these obsolete macros until such
a time as labeled networking is again possible.

Index: policy/domains/program/ssh.te
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/policy/domains/program/ssh.te,v
retrieving revision 1.32
diff -u -r1.32 ssh.te
--- policy/domains/program/ssh.te	30 Jul 2004 18:49:08 -0000	1.32
+++ policy/domains/program/ssh.te	2 Aug 2004 15:35:38 -0000
@@ -6,6 +6,12 @@
 # X-Debian-Packages: ssh
 #
 
+# Allow ssh logins as sysadm_r:sysadm_t
+bool ssh_sysadm_login false;
+
+# Allow ssh to run from inetd instead of as a daemon.
+bool run_ssh_inetd false;
+
 # sshd_exec_t is the type of the sshd executable.
 # sshd_key_t is the type of the ssh private key files
 type sshd_exec_t, file_type, exec_type, sysadmfile;
@@ -13,12 +19,6 @@
 
 type ssh_port_t, port_type;
 
-ifdef(`inetd.te', `
-ifdef(`run_ssh_inetd', `
-define(`using_ssh_inetd', `')
-')
-')dnl end if inetd
-
 define(`sshd_program_domain', `
 # privowner is for changing the identity on the terminal device
 # privfd is for passing the terminal file handle to the user process
@@ -78,13 +78,13 @@
 ')dnl end if nfs_home_dirs
 
 ifdef(`single_userdomain', `
-ifdef(`ssh_sysadm_login', `
+if (ssh_sysadm_login) {
 allow $1_t home_type:dir { getattr search };
 allow $1_t home_type:file { getattr read };
-', `
+} else {
 allow $1_t user_home_type:dir { getattr search };
 allow $1_t user_home_type:file { getattr read };
-')dnl end ssh sysadm login
+} dnl end ssh sysadm login
 ')dnl end single userdomain
 
 # Set exec context.
@@ -145,11 +145,11 @@
 # sshd_extern_t is the domain for ssh from outside our network
 #
 sshd_program_domain(sshd)
-ifdef(`ssh_sysadm_login', `
+if (ssh_sysadm_login) {
 sshd_spawn_domain(sshd, userdomain, { sysadm_devpts_t userpty_type })
-', `
+} else {
 sshd_spawn_domain(sshd, unpriv_userdomain, userpty_type)
-')
+}
 
 ifdef(`use_x_ports', `
 # for X forwarding
@@ -168,14 +168,14 @@
 allow sshd_t mail_spool_t:lnk_file read;
 allow sshd_t mail_spool_t:file getattr;
 
-ifdef(`using_ssh_inetd', `
+if (run_ssh_inetd) {
 allow inetd_t ssh_port_t:tcp_socket name_bind;
 domain_auto_trans(inetd_t, sshd_exec_t, sshd_t)
 domain_trans(inetd_t, sshd_exec_t, sshd_extern_t)
 allow { sshd_t sshd_extern_t } inetd_t:tcp_socket rw_socket_perms;
 allow { sshd_t sshd_extern_t } var_run_t:dir { getattr search };
 allow { sshd_t sshd_extern_t } self:process signal;
-', `
+} else {
 allow { sshd_t sshd_extern_t } initrc_devpts_t:chr_file rw_file_perms;
 allow { sshd_t sshd_extern_t } self:capability net_bind_service;
 allow { sshd_t sshd_extern_t } ssh_port_t:tcp_socket name_bind;
@@ -189,11 +189,11 @@
 
 # Inherit and use descriptors from init.
 allow { sshd_t sshd_extern_t } init_t:fd use;
+}
 
 # Create /var/run/sshd.pid
 var_run_domain(sshd)
 var_run_domain(sshd_extern)
-')
 
 ifdef(`direct_sysadm_daemon', `
 # Direct execution by sysadm_r.
Index: policy/macros/program/ssh_macros.te
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/policy/macros/program/ssh_macros.te,v
retrieving revision 1.16
diff -u -r1.16 ssh_macros.te
--- policy/macros/program/ssh_macros.te	26 Jul 2004 19:45:05 -0000	1.16
+++ policy/macros/program/ssh_macros.te	2 Aug 2004 15:40:40 -0000
@@ -130,16 +130,6 @@
 # Inherit and use descriptors from gnome-pty-helper.
 ifdef(`gnome-pty-helper.te', `allow $1_ssh_t $1_gph_t:fd use;')
 
-# Connect to sshd.
-ifdef(`inetd.te', `
-ifdef(`run_ssh_inetd', `
-can_tcp_connect($1_ssh_t, inetd_t)
-', `
-can_tcp_connect($1_ssh_t, sshd_t)
-')', `
-can_tcp_connect($1_ssh_t, sshd_t)
-')
-
 # Write to the user domain tty.
 allow $1_ssh_t $1_tty_device_t:chr_file rw_file_perms;
 allow $1_ssh_t $1_devpts_t:chr_file rw_file_perms;
Index: policy/tunables/tunable.tun
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/policy/tunables/tunable.tun,v
retrieving revision 1.2
diff -u -r1.2 tunable.tun
--- policy/tunables/tunable.tun	2 Aug 2004 15:33:26 -0000	1.2
+++ policy/tunables/tunable.tun	2 Aug 2004 15:33:41 -0000
@@ -30,9 +30,6 @@
 # Support NFS home directories
 dnl define(`nfs_home_dirs')
 
-# Allow ssh to run from inetd instead of as a daemon
-dnl define(`run_ssh_inetd')
-
 # Allow users to run games
 dnl define(`use_games')
 
@@ -57,9 +54,6 @@
 # files (such as ~/.bashrc)
 dnl define(`staff_read_sysadm_file')
 
-# Allow ssh logins as sysadm_r:sysadm_t
-dnl define(`ssh_sysadm_login')
-
 # Allow user to r/w noextattrfile (FAT, CDROM, FLOPPY)
 dnl define(`user_rw_noexattrfile')
 



-- 
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Stephen Smalley]

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

On Mon, 2004-08-02 at 14:53, Stephen Smalley wrote:
> I wanted to re-open this thread of discussion regarding whether some of
> the current policy compile-time tunables should be converted to runtime
> policy booleans.  The policy tunables were originally introduced prior
> to the merging of the conditional policy support, but conditional
> support has been available in the mainline kernel since Linux 2.6.5.  I
> have created some experimental policy patches converting many of the
> base tunables from tunable.{tun,te} to booleans; these are presently
> available in the sourceforge CVS tree and I'll include one small patch
> below for reference as an example.  

BTW, if you want to experiment with these changes, you'll need the
latest checkpolicy from the sourceforge CVS tree (or apply the attached
patch to it), as there was a bug in the conditional code in checkpolicy
that was just fixed by the Tresys team.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

[-- Attachment #2: cond-self-bug-7-30-2004.patch --]
[-- Type: text/x-patch, Size: 2523 bytes --]

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/07/30 17:42:37-04:00 kmacmillan@pham.(none) 
#   Fix for self handling bug.
# 
# checkpolicy/policy_parse.y
#   2004/07/30 17:42:28-04:00 kmacmillan@pham.(none) +34 -14
#   Fix for self handling bug.
# 
diff -Nru a/checkpolicy/policy_parse.y b/checkpolicy/policy_parse.y
--- a/checkpolicy/policy_parse.y	Fri Jul 30 17:43:50 2004
+++ b/checkpolicy/policy_parse.y	Fri Jul 30 17:43:50 2004
@@ -2505,7 +2505,7 @@
 static cond_av_list_t *define_cond_te_avtab(int which)
 {
 	char *id;
-	cond_av_list_t *sub_list, *self_list, *n;
+	cond_av_list_t *sub_list, *final_list, *tail;
 	class_datum_t *cladatum;
 	perm_datum_t *perdatum;
 	ebitmap_t stypes, ttypes, tclasses, negset;
@@ -2623,27 +2623,47 @@
 		free(id);
 	}
 
-	sub_list = (cond_av_list_t *) 0;
-	self_list = (cond_av_list_t *) 0;
+	sub_list = NULL;
+	tail = NULL;
+	final_list = NULL;
+
+	if (self) {
+		for (i = ebitmap_startbit(&stypes); i < ebitmap_length(&stypes); i++) {
+			if (!ebitmap_get_bit(&stypes, i)) 
+				continue;
+			if (self) {
+				if ((sub_list = cond_te_avtab_helper(which, i, i, &tclasses, avp )) == COND_ERR)
+					return COND_ERR;
+				if (final_list) {
+					tail->next = sub_list;
+					while (tail->next != NULL)
+						tail = tail->next;
+				} else {
+					final_list = sub_list;
+					tail = final_list;
+					while (tail->next != NULL)
+						tail = tail->next;
+				}
+			}
+		}
+	}
 	for (i = ebitmap_startbit(&stypes); i < ebitmap_length(&stypes); i++) {
 		if (!ebitmap_get_bit(&stypes, i)) 
 			continue;
-		if (self) {
-			if ((self_list = cond_te_avtab_helper(which, i, i, &tclasses, avp )) == COND_ERR)
-				return COND_ERR;
-		}
 		for (j = ebitmap_startbit(&ttypes); j < ebitmap_length(&ttypes); j++) {
 			if (!ebitmap_get_bit(&ttypes, j)) 
 				continue;
 			if ((sub_list = cond_te_avtab_helper(which, i, j, &tclasses, avp)) == COND_ERR)
 				return COND_ERR;
-			/* add the self_list, if any, and the sub_list */
-			if (self_list) {
-				n = self_list;
-				while (n->next != (cond_av_list_t *)0) n = n->next;
-				n->next = sub_list;
+			if (final_list) {
+				tail->next = sub_list;
+				while (tail->next != NULL)
+					tail = tail->next;
 			} else {
-				self_list = sub_list;
+				final_list = sub_list;
+				tail = final_list;
+				while (tail->next != NULL)
+					tail = tail->next;
 			}
 		}
 	}
@@ -2653,7 +2673,7 @@
 	ebitmap_destroy(&tclasses);
 	free(avp);
 	
-	return self_list;
+	return final_list;
  bad:
 	return COND_ERR;
 }

RE: Now that SELinux supports booleans should we replace tunables with booleans?

[Stephen Smalley]

On Mon, 2004-08-02 at 14:53, Stephen Smalley wrote:
> As previously discussed, we will need a mechanism to preserve policy
> boolean values across a reboot, so we will need an equivalent to
> /etc/sysctl.conf for the policy booleans as part of the policy
> configuration under /etc/selinux, and we will need rc.sysinit to
> initialize the policy booleans accordingly as it already does for sysctl
> values.  

Dan has raised the issue of how to handle policy reloads when using
booleans, as a policy reload will reset the boolean values to the
compile-time default settings.  We could certainly extend load_policy to
also set the booleans based on the same configuration file used at boot
time, but that will leave open a window between the policy reload and
the setting of the booleans where the active policy will fall back to
the compile-time defaults.  That could break running processes or create
a window of vulnerability, depending on whether the compile-time
defaults are more secure or less secure than the configuration file
settings.  We could have the policy Makefile patch the boolean default
settings based on the configuration file, so that a policy rebuild would
change the compile-time defaults to match the desired settings, but that
requires policy sources, which may not be available (e.g. the policy
reload may have been triggered by a binary policy update, and the end
system may not have policy sources installed).  Thoughts?

-- 
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Stephen Smalley]

On Thu, 2004-08-05 at 08:30, Stephen Smalley wrote:
> Dan has raised the issue of how to handle policy reloads when using
> booleans, as a policy reload will reset the boolean values to the
> compile-time default settings.  We could certainly extend load_policy to
> also set the booleans based on the same configuration file used at boot
> time, but that will leave open a window between the policy reload and
> the setting of the booleans where the active policy will fall back to
> the compile-time defaults.  That could break running processes or create
> a window of vulnerability, depending on whether the compile-time
> defaults are more secure or less secure than the configuration file
> settings.  We could have the policy Makefile patch the boolean default
> settings based on the configuration file, so that a policy rebuild would
> change the compile-time defaults to match the desired settings, but that
> requires policy sources, which may not be available (e.g. the policy
> reload may have been triggered by a binary policy update, and the end
> system may not have policy sources installed).  Thoughts?

Actually, it would be easy to create a simple utility that patches a
binary policy to change the boolean default values, so that would be a
possibility.  

-- 
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Daniel J Walsh]

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

Stephen Smalley wrote:

>On Thu, 2004-08-05 at 08:30, Stephen Smalley wrote:
>  
>
>>Dan has raised the issue of how to handle policy reloads when using
>>booleans, as a policy reload will reset the boolean values to the
>>compile-time default settings.  We could certainly extend load_policy to
>>also set the booleans based on the same configuration file used at boot
>>time, but that will leave open a window between the policy reload and
>>the setting of the booleans where the active policy will fall back to
>>the compile-time defaults.  That could break running processes or create
>>a window of vulnerability, depending on whether the compile-time
>>defaults are more secure or less secure than the configuration file
>>settings.  We could have the policy Makefile patch the boolean default
>>settings based on the configuration file, so that a policy rebuild would
>>change the compile-time defaults to match the desired settings, but that
>>requires policy sources, which may not be available (e.g. the policy
>>reload may have been triggered by a binary policy update, and the end
>>system may not have policy sources installed).  Thoughts?
>>    
>>
>
>Actually, it would be easy to create a simple utility that patches a
>binary policy to change the boolean default values, so that would be a
>possibility.  
>
>  
>
Here is the current patch I was using for load_policy.  As has been 
stated this is not the ideal situation.
Patching the policy.conf is probably the best solution.   Utilities to 
read booleans probably usefull here.

Dan


[-- Attachment #2: policycoreutils-rhat.patch --]
[-- Type: text/x-patch, Size: 2629 bytes --]

--- policycoreutils-1.15.3/scripts/genhomedircon.rhat	2004-07-29 16:26:01.000000000 -0400
+++ policycoreutils-1.15.3/scripts/genhomedircon	2004-08-05 09:41:35.553364941 -0400
@@ -83,7 +83,7 @@
 	if rc[0] == 0:
 		print rc[1]
 	else:
-		errorExit(join("grep/sed error ", rc[1]))
+		errorExit(string.join("grep/sed error ", rc[1]))
 	return rc
 
 try:
@@ -128,7 +128,7 @@
 	if rc[0] == 0:
 		print rc[1]
 	else:
-		errorExit(join("sed error ", rc[1]))
+		errorExit(string.join("sed error ", rc[1]))
 
 	users = getUsers()
 	print "\n#\n# User-specific file contexts\n#\n"
@@ -137,6 +137,6 @@
 	for u in users.keys():
 		update(sys.argv[2], u, users[u]) 
 except ValueError, error:
-	errorExit(join("ValueError ", error))
+	errorExit(strin.join("ValueError ", error))
 except IndexError, error:
 	errorExit("IndexError")
--- policycoreutils-1.15.3/load_policy/load_policy.c.rhat	2004-08-05 09:41:55.250910627 -0400
+++ policycoreutils-1.15.3/load_policy/load_policy.c	2004-08-05 09:41:59.879803864 -0400
@@ -10,11 +10,67 @@
 #include <selinux/selinux.h>
 #include <locale.h>			    /* for setlocale() */
 #include <libintl.h>			    /* for gettext() */
+#include <ctype.h>
+
 #define _(msgid) gettext (msgid)
 #ifndef PACKAGE
 #define PACKAGE "policycoreutils"   /* the name of this package lang translation */
 #endif
 
+#define BOOLEANS "booleans"      /* booleans file */
+
+
+char *strtrim(char *dest, char *source, int size) {
+	int i=0;
+	char *ptr=source;
+	i=0;
+	while(isspace(*ptr) && i < size) {
+		ptr++;
+		i++;
+	}
+	strncpy(dest,ptr,size);
+	for(i=strlen(dest)-1; i> 0; i--) {
+		if (!isspace(dest[i])) break;
+	}
+	dest[i+1]='\0';
+	return dest;
+}
+
+int load_booleans(void) {
+	FILE *boolf;
+	char buffer[BUFSIZ];
+	char name[BUFSIZ];
+	char name1[BUFSIZ];
+	int val;
+	int errors=0;
+
+	snprintf(buffer,BUFSIZ, "%s/%s", selinux_policy_root(), BOOLEANS);
+	boolf = fopen(buffer,"r");
+	if (boolf == NULL) 
+		return errors;
+
+        while (fgets(buffer, sizeof(buffer), boolf)) {
+		char *tok=strtok(buffer,"=");
+		if (tok) {
+			strncpy(name1,tok, BUFSIZ-1);
+			strtrim(name,name1,BUFSIZ-1);
+			if ( name[0]=='#' ) continue;
+			tok=strtok(NULL,tok);
+			if (tok) {
+				val=atoi(tok);
+				if (security_set_boolean(name, val)!=0) {
+					fprintf(stderr,"error setting boolean %s to value %d \n", name, val);
+					errors++;
+				}
+			}
+		}
+	}
+	fclose(boolf);
+
+	security_commit_booleans();
+
+	return errors;
+}
 int main(int argc, char **argv) 
 {
 	int fd, ret;
@@ -55,5 +111,7 @@
 		fprintf(stderr, _("%s:  security_load_policy failed\n"), argv[0]);
 		exit(3);
 	}
+	load_booleans();
+
 	exit(0);
 }

RE: Now that SELinux supports booleans should we replace tunables with booleans?

[Stephen Smalley]

On Mon, 2004-08-02 at 14:53, Stephen Smalley wrote:
> As a minor issue, we should also reconsider the names of the boolean
> utilities, as they are too generic and could easily conflict in the
> future with other non-SELinux programs.  Also, Chris PeBenito posted a
> toggle_bool utility a while back that would likely be useful to add.

change_bool -> change_sebool
show_bools -> show_sebools
toggle_bool -> toggle_sebool

-- 
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Stephen Smalley]

On Thu, 2004-08-05 at 09:44, Daniel J Walsh wrote:
> Here is the current patch I was using for load_policy.  As has been 
> stated this is not the ideal situation.
> Patching the policy.conf is probably the best solution.   Utilities to 
> read booleans probably usefull here.

As an interim solution, I've merged a slightly modified form of this
function into libselinux and changed load_policy to call it; /sbin/init
can likewise be changed to call it after the initial policy load to set
the boolean values.  But we'll still want to pursue a solution that lets
us re-patch the boolean default settings directly in the binary policy
so that there is no interval where the settings are wrong during a
policy reload.

-- 
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Joshua Brindle]

Stephen Smalley wrote:
> On Mon, 2004-08-02 at 14:53, Stephen Smalley wrote:
> 
>>As a minor issue, we should also reconsider the names of the boolean
>>utilities, as they are too generic and could easily conflict in the
>>future with other non-SELinux programs.  Also, Chris PeBenito posted a
>>toggle_bool utility a while back that would likely be useful to add.
> 
> 
> change_bool -> change_sebool
> show_bools -> show_sebools
> toggle_bool -> toggle_sebool
> 

If they are going to be changed they should probably also be changed to 
match the get/set convention used by most other selinux apps.

Joshua Brindle

--
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Stephen Smalley]

On Mon, 2004-08-02 at 14:53, Stephen Smalley wrote:
> Of the remaining base tunables from tunable.tun, I believe that either
> they are not amenable to the use of policy booleans (i.e. affect type
> declarations or role-based statements) or they would activate many
> additional rules when enabled and it would thus bloat the policy to make
> them runtime conditionals.  However, I'm open to reconsidering some of
> the latter cases, and even to re-thinking how we approach some of the
> former cases to allow us to leverage booleans to some degree.

BTW, I was hoping for a bit more discussion about which tunables should
remain as compile-time tunables, and which ones should be runtime
booleans.  I've converted about half of the base tunables and all of the
named and apache tunables to booleans.  There are still at least some
tunables that I can envision admins wanting to be able to change as
booleans, but would require further reworking of the policy to split out
the parts that cannot be made conditional, and there may be some
booleans I've created that would be better to keep as static tunables. 
Comments are welcome.

-- 
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Stephen Smalley]

On Fri, 2004-08-06 at 10:20, Joshua Brindle wrote:
> If they are going to be changed they should probably also be changed to 
> match the get/set convention used by most other selinux apps.

I can see renaming change_bool to setsebool or something similar, and
adding a new getsebool <boolean> that just displays the value of the
specified boolean.  show_bools is a little different in that it shows
all booleans and their values, so possibly listsebools.  toggle_sebool
has no equivalent.

-- 
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Daniel J Walsh]

Stephen Smalley wrote:

>On Fri, 2004-08-06 at 10:20, Joshua Brindle wrote:
>  
>
>>If they are going to be changed they should probably also be changed to 
>>match the get/set convention used by most other selinux apps.
>>    
>>
>
>I can see renaming change_bool to setsebool or something similar, and
>adding a new getsebool <boolean> that just displays the value of the
>specified boolean.  show_bools is a little different in that it shows
>all booleans and their values, so possibly listsebools.  toggle_sebool
>has no equivalent.
>  
>

show_bools should be getseboo -a.

Dan


--
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Daniel J Walsh]

Stephen Smalley wrote:

>On Mon, 2004-08-02 at 14:53, Stephen Smalley wrote:
>  
>
>>Of the remaining base tunables from tunable.tun, I believe that either
>>they are not amenable to the use of policy booleans (i.e. affect type
>>declarations or role-based statements) or they would activate many
>>additional rules when enabled and it would thus bloat the policy to make
>>them runtime conditionals.  However, I'm open to reconsidering some of
>>the latter cases, and even to re-thinking how we approach some of the
>>former cases to allow us to leverage booleans to some degree.
>>    
>>
>
>BTW, I was hoping for a bit more discussion about which tunables should
>remain as compile-time tunables, and which ones should be runtime
>booleans.  I've converted about half of the base tunables and all of the
>named and apache tunables to booleans.  There are still at least some
>tunables that I can envision admins wanting to be able to change as
>booleans, but would require further reworking of the policy to split out
>the parts that cannot be made conditional, and there may be some
>booleans I've created that would be better to keep as static tunables. 
>Comments are welcome.
>
>  
>
I have not studied the booleans that closely.  But I it seems to me that 
booleans are something
that Admins would like to work with, versus tunables being something 
that distributions are going
to make decisions on.  Of course it is not that clean.  The  best thing 
about booleans is that the source
code is not required.

I think there are several tunables that can be removed.

Dan

--
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Stephen Smalley]

On Fri, 2004-08-06 at 10:40, Daniel J Walsh wrote:
> I have not studied the booleans that closely.  But I it seems to me that 
> booleans are something
> that Admins would like to work with, versus tunables being something 
> that distributions are going
> to make decisions on.  Of course it is not that clean.  The  best thing 
> about booleans is that the source
> code is not required.
> 
> I think there are several tunables that can be removed.

Ok, so it would be helpful to review the current set of booleans and
tunables to see how well they match up against this general criteria,
and to also check which ones can be removed entirely.  The present
breakdown is really only based on whether or not the existing tunable
could be easily converted to a boolean (i.e. only covered TE avtab
rules, relatively localized, small number of affected rules).

Current set of booleans (strict policy) are:
allow_xserver_home_fonts
cron_can_relabel
ftpd_is_daemon
ftp_home_dir
httpd_enable_cgi
httpd_enable_homedirs
httpd_ssi_exec
mozilla_readhome
mozilla_writehome
named_write_master_zones
read_default_t
run_ssh_inetd
secure_mode
ssh_sysadm_login
staff_read_sysadm_file
user_direct_mouse
user_dmesg
user_ping
user_rw_noexattrfile
user_rw_usb
user_tcp_server
user_ttyfile_stat
xdm_sysadm_login

Current set of policy tunables are:
nscd_all_connect
user_net_control
user_can_mount
unlimitedRPM
unlimitedUtils
nfs_home_dirs
use_games
allow_ypbind
unlimitedRC
direct_sysadm_daemon
hide_broken_symptoms
unrestricted_admin
nfs_export_all_rw
unlimitedUsers
nfs_export_all_ro
user_canbe_sysadm
unlimitedInetd

-- 
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Stephen Smalley]

On Fri, 2004-08-06 at 10:38, Daniel J Walsh wrote:
> show_bools should be getsebool -a.

Ok, committed.

show_bools -> getsebool -a or getsebool boolean...
change_bool -> setsebool
toggle_bool -> togglesebool

-- 
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: Now that SELinux supports booleans should we replace tunables with booleans?

[kmacmillan]

On Fri, 6 Aug 2004, Daniel J Walsh wrote:

> Stephen Smalley wrote:
> 
> >On Fri, 2004-08-06 at 10:20, Joshua Brindle wrote:
> >  
> >
> >>If they are going to be changed they should probably also be changed to 
> >>match the get/set convention used by most other selinux apps.
> >>    
> >>
> >
> >I can see renaming change_bool to setsebool or something similar, and
> >adding a new getsebool <boolean> that just displays the value of the
> >specified boolean.  show_bools is a little different in that it shows
> >all booleans and their values, so possibly listsebools.  toggle_sebool
> >has no equivalent.
> >  
> >
> 
> show_bools should be getseboo -a.
> 

This sounds like a good solution to me:

	change_bool	->	setsebool
	show_bools	->	getsebool (with -a showing all)
	toogle_bool	->	togglesebool

Karl

> Dan
> 


--
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: Now that SELinux supports booleans should we replace tunableswith booleans?

[Karl MacMillan]

----- Original Message ----- 
From: "Stephen Smalley" <sds@epoch.ncsc.mil>
To: <selinux@tycho.nsa.gov>
Cc: "Russell Coker" <russell@coker.com.au>; "Daniel J Walsh"
<dwalsh@redhat.com>; <selinux-dev@tresys.com>
Sent: Thursday, August 05, 2004 8:33 AM
Subject: RE: Now that SELinux supports booleans should we replace
tunableswith booleans?


> On Thu, 2004-08-05 at 08:30, Stephen Smalley wrote:
> > Dan has raised the issue of how to handle policy reloads when using
> > booleans, as a policy reload will reset the boolean values to the
> > compile-time default settings.  We could certainly extend load_policy to
> > also set the booleans based on the same configuration file used at boot
> > time, but that will leave open a window between the policy reload and
> > the setting of the booleans where the active policy will fall back to
> > the compile-time defaults.  That could break running processes or create
> > a window of vulnerability, depending on whether the compile-time
> > defaults are more secure or less secure than the configuration file
> > settings.  We could have the policy Makefile patch the boolean default
> > settings based on the configuration file, so that a policy rebuild would
> > change the compile-time defaults to match the desired settings, but that
> > requires policy sources, which may not be available (e.g. the policy
> > reload may have been triggered by a binary policy update, and the end
> > system may not have policy sources installed).  Thoughts?
>
> Actually, it would be easy to create a simple utility that patches a
> binary policy to change the boolean default values, so that would be a
> possibility.
>

Just changing the booleans isn't enough - you would also need to evaluate
all of the expressions and set rules to active/inactive. If you were
planning to take the same approach as the user management tool that you just
did, this should be trivial. The other option is that the reading code could
be changed to evaluate all of the expressions after loading a policy so that
changes to the booleans would become active, but that would obviously
require kernel changes.

For the reload case, the only other idea that I can think of is to have
security_load_policy copy the current boolean states to the newly loaded
policy for booleans that are shared between the policies. I'm not certain
this is a good idea - and you probably want to have a way to disable the
behavior - but the advantage is that it allows booleans to be persistent
while a machine is running without requiring them to be persistent across
reboots. It seems to me that persistance across reboots is actually a
separate case and I am concerned about administrator confusion about when a
change to a boolean is temporary and when it is persistent. I agree,
however, that it is important to have some safe mechanisms for making the
boolean states stay during reload and reboots.

Karl

> -- 
> 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: Now that SELinux supports booleans should we replace tunableswith booleans?

[Stephen Smalley]

On Fri, 2004-08-06 at 11:57, Karl MacMillan wrote:
> Just changing the booleans isn't enough - you would also need to evaluate
> all of the expressions and set rules to active/inactive. If you were
> planning to take the same approach as the user management tool that you just
> did, this should be trivial.

Yes, it shouldn't be difficult to create a genpolbools utility similar
to the recently created genpolusers utility.  However, I think that Dan
would want the functionality available as a library function that
operates entirely in-memory rather than on files, so that load_policy
can directly invoke it on the mmap'd policy file to rewrite the binary
policy in memory based on the separate saved boolean settings prior to
loading it into the kernel.  

> For the reload case, the only other idea that I can think of is to have
> security_load_policy copy the current boolean states to the newly loaded
> policy for booleans that are shared between the policies. I'm not certain
> this is a good idea - and you probably want to have a way to disable the
> behavior - but the advantage is that it allows booleans to be persistent
> while a machine is running without requiring them to be persistent across
> reboots. It seems to me that persistance across reboots is actually a
> separate case and I am concerned about administrator confusion about when a
> change to a boolean is temporary and when it is persistent. I agree,
> however, that it is important to have some safe mechanisms for making the
> boolean states stay during reload and reboots.

Under the proposed scheme, reboots and policy reloads would set the
booleans to the values saved in /etc/selinux/$SELINUXTYPE/booleans
(defaulting to the compile-time defaults if there was no value saved in
that file for a given boolean).  Admins would edit that file (directly
or using a tool) if they wanted the boolean setting to persist; if they
only want a temporary change that will be reverted by a reboot or policy
reload, then they would use setsebool to make that temporary change.  

-- 
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: Now that SELinux supports booleans should we replace tunableswith booleans?

[Stephen Smalley]

On Fri, 2004-08-06 at 12:20, Stephen Smalley wrote:
> Yes, it shouldn't be difficult to create a genpolbools utility similar
> to the recently created genpolusers utility.  However, I think that Dan
> would want the functionality available as a library function that
> operates entirely in-memory rather than on files, so that load_policy
> can directly invoke it on the mmap'd policy file to rewrite the binary
> policy in memory based on the separate saved boolean settings prior to
> loading it into the kernel.

This has now been implemented in the sourceforge CVS tree; the
checkpolicy core logic has been moved into a libsepol library, a
sepol_genbools() function for rewriting a binary policy in memory for
new boolean definitions has been added to libsepol, and load_policy has
been changed to use this function prior to reloading the policy.  A
separate genpolbools utility that performs the same transformation but
with files as input and output has also been added to the checkpolicy
tree.

> Under the proposed scheme, reboots and policy reloads would set the
> booleans to the values saved in /etc/selinux/$SELINUXTYPE/booleans
> (defaulting to the compile-time defaults if there was no value saved in
> that file for a given boolean).  Admins would edit that file (directly
> or using a tool) if they wanted the boolean setting to persist; if they
> only want a temporary change that will be reverted by a reboot or policy
> reload, then they would use setsebool to make that temporary change.

Karl has suggested that while /sbin/init should use this technique for
preserving booleans across reboots, /usr/sbin/load_policy should just
get the current boolean settings from selinuxfs and use them for policy
reloads, so that booleans do not change upon a policy reload by
default.  This is to ensure that booleans that represent system state
are not perturbed by policy reloads.  What do others think?

-- 
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: Now that SELinux supports booleans should we replace tunableswith booleans?

[Russell Coker]

On Tue, 10 Aug 2004 06:11, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> > Under the proposed scheme, reboots and policy reloads would set the
> > booleans to the values saved in /etc/selinux/$SELINUXTYPE/booleans
> > (defaulting to the compile-time defaults if there was no value saved in
> > that file for a given boolean).  Admins would edit that file (directly
> > or using a tool) if they wanted the boolean setting to persist; if they
> > only want a temporary change that will be reverted by a reboot or policy
> > reload, then they would use setsebool to make that temporary change.
>
> Karl has suggested that while /sbin/init should use this technique for
> preserving booleans across reboots, /usr/sbin/load_policy should just
> get the current boolean settings from selinuxfs and use them for policy
> reloads, so that booleans do not change upon a policy reload by
> default.  This is to ensure that booleans that represent system state
> are not perturbed by policy reloads.  What do others think?

Sounds good.

-- 
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: Now that SELinux supports booleans should we replace tunableswith booleans?

[Daniel J Walsh]

Stephen Smalley wrote:

>On Fri, 2004-08-06 at 12:20, Stephen Smalley wrote:
>  
>
>>Yes, it shouldn't be difficult to create a genpolbools utility similar
>>to the recently created genpolusers utility.  However, I think that Dan
>>would want the functionality available as a library function that
>>operates entirely in-memory rather than on files, so that load_policy
>>can directly invoke it on the mmap'd policy file to rewrite the binary
>>policy in memory based on the separate saved boolean settings prior to
>>loading it into the kernel.
>>    
>>
>
>This has now been implemented in the sourceforge CVS tree; the
>checkpolicy core logic has been moved into a libsepol library, a
>sepol_genbools() function for rewriting a binary policy in memory for
>new boolean definitions has been added to libsepol, and load_policy has
>been changed to use this function prior to reloading the policy.  A
>separate genpolbools utility that performs the same transformation but
>with files as input and output has also been added to the checkpolicy
>tree.
>
>  
>
>>Under the proposed scheme, reboots and policy reloads would set the
>>booleans to the values saved in /etc/selinux/$SELINUXTYPE/booleans
>>(defaulting to the compile-time defaults if there was no value saved in
>>that file for a given boolean).  Admins would edit that file (directly
>>or using a tool) if they wanted the boolean setting to persist; if they
>>only want a temporary change that will be reverted by a reboot or policy
>>reload, then they would use setsebool to make that temporary change.
>>    
>>
>
>Karl has suggested that while /sbin/init should use this technique for
>preserving booleans across reboots, /usr/sbin/load_policy should just
>get the current boolean settings from selinuxfs and use them for policy
>reloads, so that booleans do not change upon a policy reload by
>default.  This is to ensure that booleans that represent system state
>are not perturbed by policy reloads.  What do others think?
>
>  
>
I agree with Karl.  Maybe a switch to load_policy to restore system 
defaults.

Dan


--
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: Now that SELinux supports booleans should we replace tunableswith booleans?

[Karl MacMillan]

> -----Original Message-----
> From: Russell Coker [mailto:russell@coker.com.au]
> Sent: Tuesday, August 10, 2004 2:47 AM
> To: Stephen Smalley
> Cc: Karl MacMillan; selinux@tycho.nsa.gov; Daniel J Walsh; selinux-
> dev@tresys.com
> Subject: Re: Now that SELinux supports booleans should we replace
> tunableswith booleans?
> 
> On Tue, 10 Aug 2004 06:11, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> > > Under the proposed scheme, reboots and policy reloads would set the
> > > booleans to the values saved in /etc/selinux/$SELINUXTYPE/booleans
> > > (defaulting to the compile-time defaults if there was no value saved
> in
> > > that file for a given boolean).  Admins would edit that file (directly
> > > or using a tool) if they wanted the boolean setting to persist; if
> they
> > > only want a temporary change that will be reverted by a reboot or
> policy
> > > reload, then they would use setsebool to make that temporary change.
> >
> > Karl has suggested that while /sbin/init should use this technique for
> > preserving booleans across reboots, /usr/sbin/load_policy should just
> > get the current boolean settings from selinuxfs and use them for policy
> > reloads, so that booleans do not change upon a policy reload by
> > default.  This is to ensure that booleans that represent system state
> > are not perturbed by policy reloads.  What do others think?
> 
> Sounds good.
> 

Another question is what happens if you change the default value in the
policy source? Under this suggestion, the new default would not take effect
until a reboot and then only if the config file doesn't specify the boolean
value. Not certain if this is a problem, but it is kind of strange and
potentially surprising to policy authors.

Karl

Karl MacMillan
Tresys Technology
http://www.tresys.com
(410)290-1411 ext 134

> --
> 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: Now that SELinux supports booleans should we replace tunableswith booleans?

[Daniel J Walsh]

Karl MacMillan wrote:

>>-----Original Message-----
>>From: Russell Coker [mailto:russell@coker.com.au]
>>Sent: Tuesday, August 10, 2004 2:47 AM
>>To: Stephen Smalley
>>Cc: Karl MacMillan; selinux@tycho.nsa.gov; Daniel J Walsh; selinux-
>>dev@tresys.com
>>Subject: Re: Now that SELinux supports booleans should we replace
>>tunableswith booleans?
>>
>>On Tue, 10 Aug 2004 06:11, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
>>    
>>
>>>>Under the proposed scheme, reboots and policy reloads would set the
>>>>booleans to the values saved in /etc/selinux/$SELINUXTYPE/booleans
>>>>(defaulting to the compile-time defaults if there was no value saved
>>>>        
>>>>
>>in
>>    
>>
>>>>that file for a given boolean).  Admins would edit that file (directly
>>>>or using a tool) if they wanted the boolean setting to persist; if
>>>>        
>>>>
>>they
>>    
>>
>>>>only want a temporary change that will be reverted by a reboot or
>>>>        
>>>>
>>policy
>>    
>>
>>>>reload, then they would use setsebool to make that temporary change.
>>>>        
>>>>
>>>Karl has suggested that while /sbin/init should use this technique for
>>>preserving booleans across reboots, /usr/sbin/load_policy should just
>>>get the current boolean settings from selinuxfs and use them for policy
>>>reloads, so that booleans do not change upon a policy reload by
>>>default.  This is to ensure that booleans that represent system state
>>>are not perturbed by policy reloads.  What do others think?
>>>      
>>>
>>Sounds good.
>>
>>    
>>
>
>Another question is what happens if you change the default value in the
>policy source? Under this suggestion, the new default would not take effect
>until a reboot and then only if the config file doesn't specify the boolean
>value. Not certain if this is a problem, but it is kind of strange and
>potentially surprising to policy authors.
>  
>
Maybe load_policy should log to the syslog which boolean settings it is 
using,  Does the kernel
have any memory of booleans that were manually changed from the default?

Dan

>Karl
>
>Karl MacMillan
>Tresys Technology
>http://www.tresys.com
>(410)290-1411 ext 134
>
>  
>
>>--
>>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: Now that SELinux supports booleans should we replace tunableswith booleans?

[Stephen Smalley]

On Tue, 2004-08-10 at 10:29, Karl MacMillan wrote:
> Another question is what happens if you change the default value in the
> policy source? Under this suggestion, the new default would not take effect
> until a reboot and then only if the config file doesn't specify the boolean
> value. Not certain if this is a problem, but it is kind of strange and
> potentially surprising to policy authors.

Given the nature of booleans, policy authors can't assume anything about
default settings, or force a change in them; they are entirely up to the
system administrator.

-- 
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: Now that SELinux supports booleans should we replace tunableswith booleans?

[Karl MacMillan]

> -----Original Message-----
> From: Daniel J Walsh [mailto:dwalsh@redhat.com]
> Sent: Tuesday, August 10, 2004 10:34 AM
> >>>Karl has suggested that while /sbin/init should use this technique for
> >>>preserving booleans across reboots, /usr/sbin/load_policy should just
> >>>get the current boolean settings from selinuxfs and use them for policy
> >>>reloads, so that booleans do not change upon a policy reload by
> >>>default.  This is to ensure that booleans that represent system state
> >>>are not perturbed by policy reloads.  What do others think?
> >>>
> >>>
> >>Sounds good.
> >>
> >>
> >>
> >
> >Another question is what happens if you change the default value in the
> >policy source? Under this suggestion, the new default would not take
> effect
> >until a reboot and then only if the config file doesn't specify the
> boolean
> >value. Not certain if this is a problem, but it is kind of strange and
> >potentially surprising to policy authors.
> >
> >
> Maybe load_policy should log to the syslog which boolean settings it is
> using,  Does the kernel
> have any memory of booleans that were manually changed from the default?
> 

No - unfortunately, the booleans only store their current state and not the
default. The default could be determined from the policy, but we could only
determine if the current value matches the default not whether the value had
been manually changed. This may not be a useful distinction, but there might
be a notion that if the admin had changed the value they wanted it to
'stick' even if it was set to the same as the default.

Karl

> Dan
> 
> >Karl
> >
> >Karl MacMillan
> >Tresys Technology
> >http://www.tresys.com
> >(410)290-1411 ext 134
> >
> >
> >
> >>--
> >>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: Now that SELinux supports booleans should we replace tunableswith booleans?

[Timothy Wood]

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

Why not add an option to load_policy that would force loading of boolean
values from the policy.  If you specify that option load_policy modifies
the current boolean values to the policy defaults.  If you do not
specify the option load_policy does not touch current boolean values.

You could do the same thing with a tunable and have load_policy check
for the tunable value.

Timothy,

Karl MacMillan wrote:
|>-----Original Message-----
|>From: Russell Coker [mailto:russell@coker.com.au]
|>Sent: Tuesday, August 10, 2004 2:47 AM
|>To: Stephen Smalley
|>Cc: Karl MacMillan; selinux@tycho.nsa.gov; Daniel J Walsh; selinux-
|>dev@tresys.com
|>Subject: Re: Now that SELinux supports booleans should we replace
|>tunableswith booleans?
|>
|>On Tue, 10 Aug 2004 06:11, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
|>
|>>>Under the proposed scheme, reboots and policy reloads would set the
|>>>booleans to the values saved in /etc/selinux/$SELINUXTYPE/booleans
|>>>(defaulting to the compile-time defaults if there was no value saved
|>
|>in
|>
|>>>that file for a given boolean).  Admins would edit that file (directly
|>>>or using a tool) if they wanted the boolean setting to persist; if
|>
|>they
|>
|>>>only want a temporary change that will be reverted by a reboot or
|>
|>policy
|>
|>>>reload, then they would use setsebool to make that temporary change.
|>>
|>>Karl has suggested that while /sbin/init should use this technique for
|>>preserving booleans across reboots, /usr/sbin/load_policy should just
|>>get the current boolean settings from selinuxfs and use them for policy
|>>reloads, so that booleans do not change upon a policy reload by
|>>default.  This is to ensure that booleans that represent system state
|>>are not perturbed by policy reloads.  What do others think?
|>
|>Sounds good.
|>
|
|
| Another question is what happens if you change the default value in the
| policy source? Under this suggestion, the new default would not take
effect
| until a reboot and then only if the config file doesn't specify the
boolean
| value. Not certain if this is a problem, but it is kind of strange and
| potentially surprising to policy authors.
|
| Karl
|
| Karl MacMillan
| Tresys Technology
| http://www.tresys.com
| (410)290-1411 ext 134
|
|
|>--
|>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.
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBGQB5PT0XLCkCs2ARAiGrAJ4pvPGpZEPrWO8Z8yOB0iXueXK4pgCgiHoj
/IU4/SscNhayiOvwMUEtItc=
=bZ0L
-----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: Now that SELinux supports booleans should we replace tunableswith booleans?

[Stephen Smalley]

On Tue, 2004-08-10 at 13:06, Timothy Wood wrote:
> Why not add an option to load_policy that would force loading of boolean
> values from the policy.  If you specify that option load_policy modifies
> the current boolean values to the policy defaults.  If you do not
> specify the option load_policy does not touch current boolean values.
> 
> You could do the same thing with a tunable and have load_policy check
> for the tunable value.

The latest version of load_policy in the sourceforge CVS tree defaults
to preserving the current boolean settings set under /selinux/booleans,
but has a '-b' option to instead set the booleans to the boot-time
boolean defaults defined by /etc/selinux/$SELINUXTYPE/booleans (or
optionally another specified file).  We could add another option as you
suggest, although in that case, load_policy doesn't have to modify
anything - it just loads the binary policy unmodified, and the kernel
will automatically reset the booleans to the compile-time policy
defaults.  It is only the case where we want to preserve the current
boolean settings or the boot-time boolean defaults that we need to
modify the in-memory policy prior to loading.  Tunables aren't
applicable here, as they are purely a policy source construct (actually
a preprocessor construct), and aren't visible to load_policy in any way.

It would be easy to add such an option, but I'm not clear if that is
what one would want.  If you truly want to force a reset to the
compile-time policy defaults, you could just remove
/etc/selinux/$SELINUXTYPE/booleans prior to calling load_policy -b.  If
you don't remove the booleans file, then it is going to reset back to
the boot-time configuration upon next boot, which is likely not what you
want if your goal is to force use of the compile-time defaults.

-- 
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: Now that SELinux supports booleans should we replace tunables with booleans?

[Daniel J Walsh]

Stephen Smalley wrote:

>On Fri, 2004-08-06 at 10:40, Daniel J Walsh wrote:
>  
>
>>I have not studied the booleans that closely.  But I it seems to me that 
>>booleans are something
>>that Admins would like to work with, versus tunables being something 
>>that distributions are going
>>to make decisions on.  Of course it is not that clean.  The  best thing 
>>about booleans is that the source
>>code is not required.
>>
>>I think there are several tunables that can be removed.
>>    
>>
>
>Ok, so it would be helpful to review the current set of booleans and
>tunables to see how well they match up against this general criteria,
>and to also check which ones can be removed entirely.  The present
>breakdown is really only based on whether or not the existing tunable
>could be easily converted to a boolean (i.e. only covered TE avtab
>rules, relatively localized, small number of affected rules).
>
>Current set of booleans (strict policy) are:
>allow_xserver_home_fonts
>cron_can_relabel
>ftpd_is_daemon
>ftp_home_dir
>httpd_enable_cgi
>httpd_enable_homedirs
>httpd_ssi_exec
>mozilla_readhome
>mozilla_writehome
>named_write_master_zones
>read_default_t
>run_ssh_inetd
>secure_mode
>ssh_sysadm_login
>staff_read_sysadm_file
>user_direct_mouse
>user_dmesg
>user_ping
>user_rw_noexattrfile
>user_rw_usb
>user_tcp_server
>user_ttyfile_stat
>xdm_sysadm_login
>
>Current set of policy tunables are:
>nscd_all_connect
>user_net_control
>user_can_mount
>unlimitedRPM
>unlimitedUtils
>nfs_home_dirs
>use_games
>allow_ypbind
>unlimitedRC
>direct_sysadm_daemon
>hide_broken_symptoms
>unrestricted_admin
>nfs_export_all_rw
>unlimitedUsers
>nfs_export_all_ro
>user_canbe_sysadm
>unlimitedInetd
>
>  
>
I think we can get rid of unlimitedUsers, you really should run targeted 
policy for this.
single_userdomain should also be removed since I don't think anyone has 
run it and they should use targeted policy.
I am not sure unrestricted_admin is needed although this has been turned 
on in Fedora Policy.
nfs_export_all should be made one tunable and then have a boolean to 
allow RW or not.


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