Policy changes for policy management

Policy changes for policy management

[Frank Mayer]

We're in the middle of putting together policy changes for managing the
policy itself.  Among other reasons, we need this to build a policy for
our seuser tool.  Others have mentioned similar work  looking at
operational management policies.  This is not as straightforward as I had
hope. The current best solution we can devise can only be a partial
solution until we create a policy management daemon that will manage the
policy pieces and run in a very controlled domain.  Until then we must
still allow the sysadm_t domain, with its ability to run just about any
program, significant access to policy files.  Nonetheless I see that as a
temporary issue; we can put the infrastructure in place using
policy_config_t and policy_src_t, with some additions, and begin the
discipline of a DTE policy for policy management.

I want to outline what we're doing and raise some issues, in order to see
what others think as well as hopefully motivate some changes in
checkpolicy.

The primary types and domains we are using are as such:

policy_src_t: The source files used to create a policy.  As I and others
have mentioned before, we believe that the policy.conf file is the
ultimate source file.  We are making proposed changes to the Makefile to
install the policy.conf file as well as the ./policy/ make directory, and
to ensure that the installed binary policy file is only ever built from
the installed policy.conf file (the policy make directory is one means of
generating the plicy.conf file).

policy_config_t: The label for the binary file as is currently used.

checkpolicy_t: The domain for the checkpolicy program.  Our goal is that
this domain be restricted to read only policy_sr_t files, and is the ONLY
domain capable of writing the installed binary file type (policy_config_t).

PROBLEM: Currently the Makefile uses gzip to compress the binary file.
This is the only issue we can't resolve so far via changes to the
Makefile.  We would like (hint, hint) checkpolicy to incorporate the zlib
or similar library so that the src-->binary translation is all handled
within the checkpolicy program (and domain). An interim solution might be
for checkpolicy to fork/exec a gzip process directly within its current
domain??

load_policy_t: The domain for load_policy program.  The goal is that this
domain (except for kernel_t) be the only domain with load_policy access to
the security object.  We haven't tested this yet, but foresee no problems.

We're also making several other proposed changes to the current policy
Makefile to conform with the above.

Comments, complaints, suggestions, etc?? We're still testing.

Also, any suggestions where the policy source files (both the installed
policy.conf and the policy make directory) might be installed.  For now
we're using /etc/security/selinux/src for both, but really have no strong
opinion about the location of these.


Frank



--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Policy changes for policy management

[Brian May]

On Thu, Jul 25, 2002 at 06:32:56PM -0400, Frank Mayer wrote:
> The primary types and domains we are using are as such:
> 
> policy_src_t: The source files used to create a policy.  As I and others
> have mentioned before, we believe that the policy.conf file is the
> ultimate source file.  We are making proposed changes to the Makefile to
> install the policy.conf file as well as the ./policy/ make directory, and
> to ensure that the installed binary policy file is only ever built from
> the installed policy.conf file (the policy make directory is one means of
> generating the plicy.conf file).

What do you mean by "source"? When I here the word "source" I think of
the M4 files the sysadm edits.

Do you plan to remove this M4 processing, or do you have another
definition for the word source?

I am working on a proposal to insert more structure into the
source file for policy.conf, so I don't want to step on anybodies
toes (if at all possible).

> policy_config_t: The label for the binary file as is currently used.
> 
> checkpolicy_t: The domain for the checkpolicy program.  Our goal is that
> this domain be restricted to read only policy_sr_t files, and is the ONLY
> domain capable of writing the installed binary file type (policy_config_t).

Sounds good.

> PROBLEM: Currently the Makefile uses gzip to compress the binary file.
> This is the only issue we can't resolve so far via changes to the
> Makefile.  We would like (hint, hint) checkpolicy to incorporate the zlib
> or similar library so that the src-->binary translation is all handled
> within the checkpolicy program (and domain). An interim solution might be
> for checkpolicy to fork/exec a gzip process directly within its current
> domain??

Another suggestion (which you may not like): Make the Makefile
executeable by putting "#!/usr/bin/make -f" at the top, and use this
to trigger the domain transition.

> load_policy_t: The domain for load_policy program.  The goal is that this
> domain (except for kernel_t) be the only domain with load_policy access to
> the security object.  We haven't tested this yet, but foresee no problems.

Again sounds good.

> We're also making several other proposed changes to the current policy
> Makefile to conform with the above.
> 
> Comments, complaints, suggestions, etc?? We're still testing.
-- 
Brian May <bam@snoopy.apana.org.au>

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Policy changes for policy management

[Stephen Smalley]

On Thu, 25 Jul 2002, Frank Mayer wrote:

> PROBLEM: Currently the Makefile uses gzip to compress the binary file.
> This is the only issue we can't resolve so far via changes to the
> Makefile.  We would like (hint, hint) checkpolicy to incorporate the zlib
> or similar library so that the src-->binary translation is all handled
> within the checkpolicy program (and domain). An interim solution might be
> for checkpolicy to fork/exec a gzip process directly within its current
> domain??

This can certainly be done, although no promises on when it will be done.
Unless, of course, someone wants to submit a patch for it (hint, hint).
As a side note, notice that it is not necessary to gzip the binary file
prior to loading - the kernel security server will accept either form,
gzipped or not.  We could simply refrain from gzip'ing the policy by
default, only doing this for initrd policies where space is at a premium.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Policy changes for policy management

[Frank Mayer]

> > policy_src_t: The source files used to create a policy.  As I and others
> > have mentioned before, we believe that the policy.conf file is the
> > ultimate source file.  We are making proposed changes to the Makefile to
> > install the policy.conf file as well as the ./policy/ make directory,
and
> > to ensure that the installed binary policy file is only ever built from
> > the installed policy.conf file (the policy make directory is one means
of
> > generating the plicy.conf file).
>
> What do you mean by "source"? When I here the word "source" I think of
> the M4 files the sysadm edits.
>
> Do you plan to remove this M4 processing, or do you have another
> definition for the word source?
>
> I am working on a proposal to insert more structure into the
> source file for policy.conf, so I don't want to step on anybodies
> toes (if at all possible).

My definition of "policy source" is the policy.conf file and anything used
to build it.  In the current distribution, the ./selinux/policy/ directory
and all its files are one method for building a policy.conf file and
would all be labeled source.  Eventually the SE Linux community willhave
other
methods of building all or parts of the policy.conf file by other methods,
and
those methods' source files will also be "policy source" files.

> > PROBLEM: Currently the Makefile uses gzip to compress the binary file.
> > This is the only issue we can't resolve so far via changes to the
> > Makefile.  We would like (hint, hint) checkpolicy to incorporate the
zlib
> > or similar library so that the src-->binary translation is all handled
> > within the checkpolicy program (and domain). An interim solution might
be
> > for checkpolicy to fork/exec a gzip process directly within its current
> > domain??
>
> Another suggestion (which you may not like): Make the Makefile
> executeable by putting "#!/usr/bin/make -f" at the top, and use this
> to trigger the domain transition.

The problem with this is that we don't want the checkpolicy_t domain able to
execute arbitrary programs.  With the above suggestions, we have to give
checkpolicy execute access to bin_t and shells, which essentially means
we provided no isolated domain.  We're already stuck with this problem
for writing policy_src_t when using make.  It would be nice if we can avoid
this
problem for write access to policy_config_t.



--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Policy changes for policy management

[Russell Coker]

On Fri, 26 Jul 2002 15:02, Frank Mayer wrote:
> > Another suggestion (which you may not like): Make the Makefile
> > executeable by putting "#!/usr/bin/make -f" at the top, and use this
> > to trigger the domain transition.
>
> The problem with this is that we don't want the checkpolicy_t domain able
> to execute arbitrary programs.  With the above suggestions, we have to give
> checkpolicy execute access to bin_t and shells, which essentially means we
> provided no isolated domain.  We're already stuck with this problem for
> writing policy_src_t when using make.  It would be nice if we can avoid
> this
> problem for write access to policy_config_t.

zlib is not too difficult to code for.  It's probably less than an hour's 
work to add zlib support to checkpolicy...  Yes, I'll do it myself eventually 
if no-one else does.

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

--
You have received this message because you are subscribed to the selinux 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.