Binary policy modules

[Mike Hearn]

Hi,

Can we have an update on this please - last I heard it was targetted for
FC5. Is this still on the cards? If so, are there any docs on how to use
it? I'm waiting for this feature so I can integrate autopackage with
SELinux (for instance by preventing packages loading kernel modules and
other risky things whilst still letting them run as root).

thanks -mike

[Stephen Smalley]

On Tue, 2005-10-11 at 21:05 +0100, Mike Hearn wrote:
>  Hi,
>  
>  Can we have an update on this please - last I heard it was targetted for
>  FC5. Is this still on the cards? If so, are there any docs on how to use
>  it? I'm waiting for this feature so I can integrate autopackage with
>  SELinux (for instance by preventing packages loading kernel modules and
>  other risky things whilst still letting them run as root). 
The module support is already in rawhide (as part of the existing
SELinux packages plus the introduction of libsemanage) but getting it
properly integrated and used there is still work in progress (but still
expected for FC5, I believe, barring any unexpected obstacles).
Documentation is woefully lacking presently, but there is a
README.MODULES in selinux-doc and some information over at 
http://sepolicy-server.sourceforge.net/index.php?page=module-language

However, by itself, the module support doesn't solve the problem of
confining packages/package managers.  It just allows policy modules to
be built and shipped separately from the base distro policy, with proper
dependency checking when they are installed.  For access control over
the policy itself, you further need the policy server, which is also
work in progress but I don't think targeted for FC5.

-- 
Stephen Smalley
National Security Agency

[Mike Hearn]

On Wed, 12 Oct 2005 12:15:42 -0400, Stephen Smalley wrote:
>  The module support is already in rawhide (as part of the existing
> SELinux
>  packages plus the introduction of libsemanage) but getting it properly
>  integrated and used there is still work in progress (but still expected
>  for FC5, I believe, barring any unexpected obstacles). Documentation is
>  woefully lacking presently, but there is a README.MODULES in selinux-doc
>  and some information over at
>  http://sepolicy-server.sourceforge.net/index.php?page=module-language 
The module language looks nice. I especially like the optionals feature,
if only ELF had that :)

>  However, by itself, the module support doesn't solve the problem
> of
>  confining packages/package managers.  It just allows policy modules to be
>  built and shipped separately from the base distro policy, with proper
>  dependency checking when they are installed.  For access control over the
>  policy itself, you further need the policy server, which is also work in
>  progress but I don't think targeted for FC5. 
Hmm, I don't quite understand - my intention was to ship a binary policy
module installed when the package manager is first installed, which then
defines a new domain almost_but_not_quite_root (with a better name of
course ;). Packages/installers would then be run in this domain instead of
being unconfined. 

Why does this need access control on the policy itself? Or do you mean,
that in FC5 it won't actually be possible to install third party
policy modules?

thanks -mike

[Stephen Smalley]

On Wed, 2005-10-12 at 19:14 +0100, Mike Hearn wrote:
>  Hmm, I don't quite understand - my intention was to ship a binary
> policy
>  module installed when the package manager is first installed, which then
>  defines a new domain almost_but_not_quite_root (with a better name of
>  course ;). Packages/installers would then be run in this domain instead of
>  being unconfined. 
Ok, that can be done without the policy server.

>  Why does this need access control on the policy itself? Or do you
> mean,
>  that in FC5 it won't actually be possible to install third party
>  policy modules? 
No, that should be possible.  What I meant was the ability to confine
the rules that can exist in a given policy module installed from a given
package, e.g. so that a policy module shipped in the foo package can't
open up read access to /etc/shadow.  That requires the policy server,
see
http://sepolicy-server.sourceforge.net/index.php

However, the good news is that the module infrastructure has been
developed with this in mind, so whether or not a module install is
performed directly on the module store by libsemanage or sent off to the
policy server for handling is hidden behind the libsemanage interface,
and the user programs like semodule use that interface.  Switching over
to the policy server just requires altering a config file for
libsemanage.

-- 
Stephen Smalley
National Security Agency

[Mike Hearn]

On Wed, 12 Oct 2005 14:24:25 -0400, Stephen Smalley wrote:
>  No, that should be possible.  What I meant was the ability to confine
> the
>  rules that can exist in a given policy module installed from a given
>  package, e.g. so that a policy module shipped in the foo package can't
>  open up read access to /etc/shadow.  That requires the policy server, see
>  http://sepolicy-server.sourceforge.net/index.php 
Wow, meta-policy? That sounds useful but mind-expanding :)

Anyway, good to know! I look forward to getting my hands on FC5 when it
comes out. It'll be interesting to see how far we can restrict installers
before we start breaking them.

thanks -mike

[Mike Hearn]

Oh, some other questions I should have asked:

* What are the binary compatibility guarantees for binary policy
  modules? Is the format stable/will it be?

* Are the .pp files cpu-architecture-neutral?

* Are they distribution neutral?

* Any other things people distributing PP files with their software should
  know?

thanks -mike

[Joshua Brindle]

Mike Hearn wrote:
>  Oh, some other questions I should have asked:
>  
>  * What are the binary compatibility guarantees for binary policy
>    modules? Is the format stable/will it be?
>   
The format is versioned the same way the kernel binary format is, so any 
changes to the format use a different version number, and backward 
compatbility is retained.

>  * Are the .pp files cpu-architecture-neutral?
>   
yes.

>  * Are they distribution neutral?
>   
only as neutral as policies are, which isn't all that neutral right now. 
  Hopefully this will change when reference policy is used by everyone 
and  optional tunables are built in to the language.

>  * Any other things people distributing PP files with their software
> should
>    know?
>   
you might look at this thread: 
http://marc.theaimsgroup.com/?l=selinux&m=112871525005860&w=2
for more information. Particularly the justification for building 
seperate packages for policy and the application.

>  thanks -mike
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>

[Mike Hearn]

On Wed, 12 Oct 2005 15:37:35 -0400, Joshua Brindle wrote:
>  The format is versioned the same way the kernel binary format is, so
> any
>  changes to the format use a different version number, and backward
>  compatbility is retained. 
That's good, but it's not what I asked. What are the binary compatibility
commitments you guys are making? Is it expected that the format will
change in future? Was it designed to be extendable? Is there some kind of
internal chunking system so new data can be added in a way that older
versions of SELinux will ignore?

>  only as neutral as policies are, which isn't all that neutral
> right now. 
Hmm, that sucks. For very simple policy like "this process can do XYZ"
shouldn't it be independent of targeted vs strict/fedora vs gentoo?
Are the capability names actually variable between distributions?

>    Hopefully this will change when reference policy is used by
> everyone
>  and  optional tunables are built in to the language. 
OK, I'm glad there's a plan for this.
 
>  you might look at this thread:
>  http://marc.theaimsgroup.com/?l=selinux&m=112871525005860&w=2 for more
>  information. Particularly the justification for building seperate packages
>  for policy and the application. 
OK. This doesn't affect autopackage so much as it's meant for third party
packages, and therefore developers are expected to define their own policy
which would be independent of strict/targeted. I question the solution
given for RPM - why not simply fix RPM so it loads policy before
installing files?

thanks -mike

[Stephen Smalley]

On Thu, 2005-10-13 at 14:55 +0100, Mike Hearn wrote:
>  On Wed, 12 Oct 2005 15:37:35 -0400, Joshua Brindle wrote:
>  > The format is versioned the same way the kernel binary format is, so any
>  > changes to the format use a different version number, and backward
>  > compatbility is retained.
>  
>  That's good, but it's not what I asked. What are the binary compatibility
>  commitments you guys are making? Is it expected that the format will
>  change in future? Was it designed to be extendable? Is there some kind of
>  internal chunking system so new data can be added in a way that older
>  versions of SELinux will ignore? 
Good questions; I don't think that this has been fully resolved.
MLS compatibility is also an issue; Fedora has enabled MLS/MCS, whereas
other distros have not yet done so, and the format is affected by that.

>  Hmm, that sucks. For very simple policy like "this process can
> do XYZ"
>  shouldn't it be independent of targeted vs strict/fedora vs gentoo?
>  Are the capability names actually variable between distributions? 
Not the "capability names" i.e. class/permission names, but the
domain/type names can vary.  To the extent that the distributions use a
common baseline for their policies, such variations should be minimal,
and the reference policy will help in that respect going forward as
well.  To date, the NSA example policy has served that purpose, but not
all distros have followed it.  In the strict vs. targeted case, you have
the issue that not all domains/types defined in the strict policy have
equivalents in the targeted policy (since strict policy confines more
processes and provides finer-grained distinctions), but that can largely
be addressed via type aliases in the targeted policy so that you can
refer to the strict policy type names regardless.

>  OK. This doesn't affect autopackage so much as it's meant for
> third party
>  packages, and therefore developers are expected to define their own policy
>  which would be independent of strict/targeted. I question the solution
>  given for RPM - why not simply fix RPM so it loads policy before
>  installing files? 
Yes, I agree with that.  One potential issue is with installing a large
number of packages; you'd like to be able to batch up all of the policy
modules into a single policy update and load, and then unpack all of the
packages.

-- 
Stephen Smalley
National Security Agency

[Mike Hearn]

On Thu, 13 Oct 2005 11:29:10 -0400, Stephen Smalley wrote:
>  Good questions; I don't think that this has been fully resolved.
> MLS
>  compatibility is also an issue; Fedora has enabled MLS/MCS, whereas other
>  distros have not yet done so, and the format is affected by that. 
Ah, right ... yes this is the sort of thing we have to watch out for. I
want to be able to distribute a single binary that works on any distro -
think commercial software, though it's useful for open source projects too.

>  Not the "capability names" i.e. class/permission names, but
> the
>  domain/type names can vary.   
Right, OK, that's what I thought. My initial target is super-simple:
restrict installers from loading kernel modules. I know there are lots of
ways around that if this is the only restriction but I want to start
simple and work up from there (next step would be to stop installers
interfering with critical system files etc).

One issue that will affect that is how uniform labelling is under /etc -
hopefully Fedora, Gentoo and any other distros that support SELinux will
move to the reference policy soon. Of course as only Fedora ships it on by
default in a desktop install for now being Fedora specific is acceptable.

>  Yes, I agree with that.  One potential issue is with installing a
> large
>  number of packages; you'd like to be able to batch up all of the policy
>  modules into a single policy update and load, and then unpack all of the
>  packages. 
Indeed. Autopackage can cope with that fine as it uses a two-phase
install, but as AP isn't designed to run a distribution but rather
distribute 3rd party software Loki Setup style, that's not much use here :)

thanks -mike

[Joshua Brindle]

Mike Hearn wrote:
>  On Wed, 12 Oct 2005 15:37:35 -0400, Joshua Brindle wrote:
>  
> >The format is versioned the same way the kernel binary format is, so any
> >changes to the format use a different version number, and backward
> >compatbility is retained.
>  
>  
>  That's good, but it's not what I asked. What are the binary compatibility
>  commitments you guys are making? Is it expected that the format will
>  change in future? Was it designed to be extendable? Is there some kind of
>  internal chunking system so new data can be added in a way that older
>  versions of SELinux will ignore?
>   
Ok, my answer was about the module format. The module format is 
versioned so that older policies will work with newer selinux systems, 
but vice versa isn't automatic, the module would need to be downgraded 
(there is a similar discussion to this on the selinux list currently)

however, the package itself isn't versioned, if the format is changed 
older systems may not be able to cope with it. This is something we need 
to look at.

>  
> >only as neutral as policies are, which isn't all that neutral right now.
>  
>  
>  Hmm, that sucks. For very simple policy like "this process can do XYZ"
>  shouldn't it be independent of targeted vs strict/fedora vs gentoo?
>  Are the capability names actually variable between distributions?
>   
in all of the mentioned policies types and attributes may or may not be 
present and may have different meanings; filesystem labels may also be 
different. modules have the ability to enable policy based on the 
presence of symbols (types, attributes, etc) and this may help some but 
probably not entirely.

>  
> >  Hopefully this will change when reference policy is used by everyone
> >and  optional tunables are built in to the language.
>  
>  
>  OK, I'm glad there's a plan for this.
>   
>  
> >you might look at this thread:
> >http://marc.theaimsgroup.com/?l=selinux&m=112871525005860&w=2 for more
> >information. Particularly the justification for building seperate packages
> >for policy and the application.
>  
>  
>  OK. This doesn't affect autopackage so much as it's meant for third party
>  packages, and therefore developers are expected to define their own policy
>  which would be independent of strict/targeted. I question the solution
>  given for RPM - why not simply fix RPM so it loads policy before
>  installing files? 
I think it is relavent because there are important concepts, proper 
integration with a package manager means several things:

The modules must be associated with the packages someway (I suggest 
dependancies)

The package manager must apply policy before installing an application, 
so that labeling will work correctly

The package manager should install policy modules to a directory it 
'owns' such as /usr/lib/selinux and then use libsemanage (semodule) to 
add modules.

The package manager should understand how policy transactions work, 
conflicting modules that must be removed/added within the same 
transaction (such targeted and strict variations of the same policy)

It should also fetch and install policy modules before installing a 
chain of applications, this way the policy isn't rebuilt/reloaded 
between every app that has a policy, which can lead to inconsistancies 
or worse, races.
>  
>  thanks -mike
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>

[Mike Hearn]

On Thu, 13 Oct 2005 11:33:05 -0400, Joshua Brindle wrote:
>  Ok, my answer was about the module format. The module format is
> versioned
>  so that older policies will work with newer selinux systems, but vice
>  versa isn't automatic, the module would need to be downgraded (there is a
>  similar discussion to this on the selinux list currently) 
Hmm, OK. As long as it's possible to generate the policy files on a
standard desktop system then this is an OK tradeoff, though for efficiency
reasons one backwards/forwards compatible file would be the best. 

What I'd really like to avoid is the sillyness we are in with header files
and symbol versions, where you need obscure tricks to build on newer and
run on older (or just do it in a VM). Having to use a VM to build portable
policy wouldn't be much fun.

>  in all of the mentioned policies types and attributes may or may not
> be
>  present and may have different meanings; filesystem labels may also be
>  different. modules have the ability to enable policy based on the presence
>  of symbols (types, attributes, etc) and this may help some but probably
>  not entirely. 
It would be nice if there were some standards on how to identify
particular vendor policy, eg:

optional {
   require { fedora_targeted_t }
   
   # fedora specific stuff goes here
}

optional {
   require { gentoo_policy_t }

   # gentoo specific stuff goes here
}

But a unified policy would be the best solution. I hope Red Hat support
the reference policy effort.

>  I think it is relavent because there are important concepts, proper
>  integration with a package manager means several things:
>  
>  The modules must be associated with the packages someway (I suggest
>  dependancies) 
Why not simply include the policy inside the package? Remember the use
case for autopackage - a non-technical user goes to the SuperTux website
and clicks the "Install SuperTux" button, Firefox downloads and opens the
autopackage and the software installs. On any distro. I don't see why
separating policy into a separate package here would be beneficial
(though it could be done, AP supports dep resolution).

>  The package manager must apply policy before installing an
> application, so
>  that labeling will work correctly 
This can certainly be done.

>  The package manager should install policy modules to a directory it
> 'owns'
>  such as /usr/lib/selinux and then use libsemanage (semodule) to add
>  modules. 
If policy can go anywhere, I'd really like to see a standard directory
like there is for .desktop files. If policy can be installed without root
in a user-specific manner in future, then having a standard location in
$HOME for it would be good.

You said they were architecture-independent, so /usr/share/policy and
$HOME/.config/policy (~/.config is a freedesktop.or thing) would seem
sensible.

>  The package manager should understand how policy transactions work,
>  conflicting modules that must be removed/added within the same transaction
>  (such targeted and strict variations of the same policy) 
Can we have more information on this? Presumably for an upstream provided
package, the answer is simply to uninstall the relevant RPM if present and
install the new package - of course if policy is in a separate package
then the old policy would still be lying around in this case.

What happens if two policy modules define conflicting policy? Is it
possible to find this out before install time?

>  It should also fetch and install policy modules before installing a
> chain
>  of applications, this way the policy isn't rebuilt/reloaded between every
>  app that has a policy, which can lead to inconsistancies or worse, races. 
That's not too hard for us to do.

thanks -mike

[Joshua Brindle]

Mike Hearn wrote:
>  On Thu, 13 Oct 2005 11:33:05 -0400, Joshua Brindle wrote:
>  
> >Ok, my answer was about the module format. The module format is versioned
> >so that older policies will work with newer selinux systems, but vice
> >versa isn't automatic, the module would need to be downgraded (there is a
> >similar discussion to this on the selinux list currently)
>  
>  
>  Hmm, OK. As long as it's possible to generate the policy files on a
>  standard desktop system then this is an OK tradeoff, though for efficiency
>  reasons one backwards/forwards compatible file would be the best. 
>  
>  What I'd really like to avoid is the sillyness we are in with header files
>  and symbol versions, where you need obscure tricks to build on newer and
>  run on older (or just do it in a VM). Having to use a VM to build portable
>  policy wouldn't be much fun.
>   
This is an interesting issue that I hadn't been thinking about..

>  
> >in all of the mentioned policies types and attributes may or may not be
> >present and may have different meanings; filesystem labels may also be
> >different. modules have the ability to enable policy based on the presence
> >of symbols (types, attributes, etc) and this may help some but probably
> >not entirely.
>  
>  
>  It would be nice if there were some standards on how to identify
>  particular vendor policy, eg:
>  
>  optional {
>     require { fedora_targeted_t }
>     
>     # fedora specific stuff goes here
>  }
>  
>  optional {
>     require { gentoo_policy_t }
>  
>     # gentoo specific stuff goes here
>  }
>  
>  But a unified policy would be the best solution. I hope Red Hat support
>  the reference policy effort.
>   
we've talked about decorative types before, it's not that elegant but it 
would probably work. It doesn't address version issues though, if you 
watch the rawhide policy development you'll see alot happening, policy 
version specific dependencies are going to be a problem I think.

>  
> >I think it is relavent because there are important concepts, proper
> >integration with a package manager means several things:
> >
> >The modules must be associated with the packages someway (I suggest
> >dependancies)
>  
>  
>  Why not simply include the policy inside the package? Remember the use
>  case for autopackage - a non-technical user goes to the SuperTux website
>  and clicks the "Install SuperTux" button, Firefox downloads and opens the
>  autopackage and the software installs. On any distro. I don't see why
>  separating policy into a separate package here would be beneficial
>  (though it could be done, AP supports dep resolution).
>  
>  
> >The package manager must apply policy before installing an application, so
> >that labeling will work correctly
>  
>  
>  This can certainly be done.
>  
>  
> >The package manager should install policy modules to a directory it 'owns'
> >such as /usr/lib/selinux and then use libsemanage (semodule) to add
> >modules.
>  
>  
>  If policy can go anywhere, I'd really like to see a standard directory
>  like there is for .desktop files. If policy can be installed without root
>  in a user-specific manner in future, then having a standard location in
>  $HOME for it would be good.
>  
>  You said they were architecture-independent, so /usr/share/policy and
>  $HOME/.config/policy (~/.config is a freedesktop.or thing) would seem
>  sensible.
>   
There should never be home or user based policies so they should go to a 
system location. It doesn't matter to me, so long as the package manager 
doesn't try mucking around in the module store directly.

>  
> >The package manager should understand how policy transactions work,
> >conflicting modules that must be removed/added within the same transaction
> >(such targeted and strict variations of the same policy)
>  
>  
>  Can we have more information on this? Presumably for an upstream provided
>  package, the answer is simply to uninstall the relevant RPM if present and
>  install the new package - of course if policy is in a separate package
>  then the old policy would still be lying around in this case.
>   
uninstalling the policy RPM won't remove it from the policy. Since the 
module installed to the system (/usr/share/selinux/policy or whatever) 
it will be removed but the one in the module store (not owned by RPM) 
wouldn't be. The RPM could probably use semodule to remove it as part of 
the uninstallation phase though. The AP packages also need to be able to 
handle this.

However, say you are changing modules, you shouldn't uninstall one and 
then install the other in seperate transactions because the applications 
labels will become invalid (file and process). Of course the install of 
the new module should try to relabel affected files, but you'd have 
process labels invalidated in the process. The correct way is to start a 
transaction, remove the old module, add the new one and commit. If the 
type names change you'd have to shut down the application beforehand and 
relabel the files afterward.

>  What happens if two policy modules define conflicting policy? Is it
>  possible to find this out before install time?
>  
They won't link so you'll get an error when you try to commit the 
transaction.

>  
> >It should also fetch and install policy modules before installing a chain
> >of applications, this way the policy isn't rebuilt/reloaded between every
> >app that has a policy, which can lead to inconsistancies or worse, races.
>  
>  
>  That's not too hard for us to do.
>   
This is the main reason I think seperate policy packages are better, if 
you are able to take all the pending packages, do the policy installs 
upfront and then the package installs it would be fine to package them 
together but the idea of doing 2 phase installs of a set of packages 
seems awkward.

[Mike Hearn]

On Thu, 13 Oct 2005 14:00:54 -0400, Joshua Brindle wrote:
>  There should never be home or user based policies so they should go
> to a
>  system location. It doesn't matter to me, so long as the package manager
>  doesn't try mucking around in the module store directly. 
Why not home/user based policies? If the user can install software to
$HOME (and they can), why not policy too? If the meta-policy stuff works
out then you should be able to impose extra restrictions/add extra rules,
but not reduce the security of the system surely?

>  uninstalling the policy RPM won't remove it from the policy.
> Since the
>  module installed to the system (/usr/share/selinux/policy or whatever) it
>  will be removed but the one in the module store (not owned by RPM)
>  wouldn't be. The RPM could probably use semodule to remove it as part of
>  the uninstallation phase though. The AP packages also need to be able to
>  handle this. 
OK.

>  However, say you are changing modules, you shouldn't uninstall
> one and
>  then install the other in seperate transactions because the applications
>  labels will become invalid (file and process). Of course the install of
>  the new module should try to relabel affected files, but you'd have
>  process labels invalidated in the process. The correct way is to start a
>  transaction, remove the old module, add the new one and commit. If the
>  type names change you'd have to shut down the application beforehand and
>  relabel the files afterward. 
Does semodule let you do this kind of atomic exchange?

thanks -mike

[Joshua Brindle]

Mike Hearn wrote:
>  On Thu, 13 Oct 2005 14:00:54 -0400, Joshua Brindle wrote:
>  
> >There should never be home or user based policies so they should go to a
> >system location. It doesn't matter to me, so long as the package manager
> >doesn't try mucking around in the module store directly.
>  
>  
>  Why not home/user based policies? If the user can install software to
>  $HOME (and they can), why not policy too? If the meta-policy stuff works
>  out then you should be able to impose extra restrictions/add extra rules,
>  but not reduce the security of the system surely?
>   
I am dubious about this but in reality it isn't necessary to keep the 
module around at all so it isn't dangerous storing them in $HOME or 
anywhere else, so long as we are controlling access to the module store 
(coarse grained access via direct semanage and fine grained via policy 
management server)

>  
> >uninstalling the policy RPM won't remove it from the policy. Since the
> >module installed to the system (/usr/share/selinux/policy or whatever) it
> >will be removed but the one in the module store (not owned by RPM)
> >wouldn't be. The RPM could probably use semodule to remove it as part of
> >the uninstallation phase though. The AP packages also need to be able to
> >handle this.
>  
>  
>  OK.
>  
>  
> >However, say you are changing modules, you shouldn't uninstall one and
> >then install the other in seperate transactions because the applications
> >labels will become invalid (file and process). Of course the install of
> >the new module should try to relabel affected files, but you'd have
> >process labels invalidated in the process. The correct way is to start a
> >transaction, remove the old module, add the new one and commit. If the
> >type names change you'd have to shut down the application beforehand and
> >relabel the files afterward.
>  
>  
>  Does semodule let you do this kind of atomic exchange?
>   
Yes.

>  thanks -mike
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>