|
Home > Archive > Debian Developers > May 2007 > Sid SELinux packages are now working
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Sid SELinux packages are now working
|
|
| Manoj Srivastava 2007-05-08, 7:22 pm |
| Hi,
There was a problem with how our refpolicy packages were put
together -- modules that were included in base where still built and
shipped in /usr/share/selinux/$policy_name/*.pp; but they could not be
installed, since there was a conflict -- they had already been
installed by base.pp
I fixed that, and with todays Sid packages, I can install either
the targeted or the strict policy, either in a minimal UML, or on my
development machine.
I think we need to create a tool that can update your policy
setup, taking into account any new packages you might have installed in
the meanwhile and loading new modules as needed. This is the first
step towards having an installation of a package automatically loading
the corresponding policy in the pre-inst phase.
An initial approach would be to have this utility be given a
package name on the command line, and it will see if there is a
corresponding selinux modular policy module, and install the policy or
update it as needed (if selinux is enabled, of course). If the module
is already installed, it should do nothing.
This way, developers can put in "update_selinux_modules $pkg"
in the preinst, without having to wait for a release when we can use
dpkg triggers.
manoj
--
General notions are generally wrong. Lady M.W. Montagu
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Erich Schubert 2007-05-08, 7:22 pm |
| Hello Manoj,
> I think we need to create a tool that can update your policy
> setup, taking into account any new packages you might have installed in
> the meanwhile and loading new modules as needed. This is the first
Like the "update-selinux-policy" command in my packages does?
http://svn.debian.org/wsvn/selinux/...-selinux-policy
> An initial approach would be to have this utility be given a
> package name on the command line, and it will see if there is a
> corresponding selinux modular policy module, and install the policy or
> update it as needed (if selinux is enabled, of course). If the module
> is already installed, it should do nothing.
Actually it might also make sense to update the modules with the latest
version in the same run. What my script doesn't do yet is check version
numbers. It will just re-run the autodetection and install any module
that was already installed or that was automatically detected.
So you can't 'blacklist' a policy module, and if you replaced it with a
modified custom one, it will also be replaced.
Local modifications in separate modules will of course be kept.
best regards,
Erich Schubert
--
erich@(vitavonni.de|debian.org) -- GPG Key ID: 4B3A135C (o_
To understand recursion you first need to understand recursion. //\
Denken ist oft schwerer, als man denkt. V_/_
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2007-05-08, 7:22 pm |
| On Wed, 09 May 2007 00:09:12 +0200, Erich Schubert <erich@debian.org> said:
> Hello Manoj,
[vbcol=seagreen]
> Like the "update-selinux-policy" command in my packages does?
> http://svn.debian.org/wsvn/selinux/...-selinux-policy
Hmm. Python. I think I looked at that when I implemented the
version in the policy postinst scripts -- I remember inverting the
mapping.
We do have something like this in the postinst of the
refpolicy packages -- something that is aware of the mapping between
SELinux policy modules and debian packages, which discovers the
relationships between modules and orders the policy load correctly, so
that it can pull in any dependency as required.
I was just thinking of pulling it out of the postinst, and
adding it into policycoreutils -- which is OK, since we already depend
on policycoreutils. I'll have to add the user interaction bits, like
specifying a single package name on the command line, and concentrating
only on that, as opposed to a general update, No options, you get a
refresh of the policy. You can optionally specify the policy name, in
case you have multiple policies installed on the system
[vbcol=seagreen]
> Actually it might also make sense to update the modules with the
> latest version in the same run. What my script doesn't do yet is
> check version numbers. It will just re-run the autodetection and
> install any module that was already installed or that was
> automatically detected.
I was thinking of looking at the module, and updating it if it
was different -- whether or not the version changed. Yes, I am lazy.
,----
| __> sha1sum /etc/selinux/refpolicy-strict/modules/active/modules/inetd.pp
| 46cb627240b2637dae973fbf11ed744e246a991d
\
| /etc/selinux/refpolicy-strict/modules/active/modules/inetd.pp
| __> sha1sum /usr/share/selinux/refpolicy-strict/inetd.pp
| 46cb627240b2637dae973fbf11ed744e246a991d
\
| /usr/share/selinux/refpolicy-strict/inetd.pp
| __>
`----
md5sum mismatch, refresh module.
> So you can't 'blacklist' a policy module, and if you replaced it with
> a modified custom one, it will also be replaced. Local modifications
> in separate modules will of course be kept.
Hmm. I had not thought about blacklisting modules. I think, if
you have a local module that overrides a refpolicy module, and so you
don't want to have the module changed at all, it should be easy enough
to implement a configuration file which sets a blacklist variable.
manoj
--
Vital papers will demonstrate their vitality by spontaneously moving
from where you left them to where you can't find them.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Erich Schubert 2007-05-09, 1:22 am |
| Hello Manoj,
> Hmm. Python. I think I looked at that when I implemented the
Well, that script actually is shell.
The Python script is what I use to do the autodetection magic.
> SELinux policy modules and debian packages, which discovers the
> relationships between modules and orders the policy load correctly, s=
o
> that it can pull in any dependency as required.
Yep, I'm generating them on compile time in my packages and storing them
in an auxillary file. shipping another 1k file with the package felt
nicer to me than computing it on install time.
> I was thinking of looking at the module, and updating it if it
> was different -- whether or not the version changed. Yes, I am lazy.
> md5sum mismatch, refresh module.
I don't think this is a good idea. If I have (for whatever reason) to
modify a policy module, I'd like to be able to bump the version number a
bit to avoid it from being updated. Like bumping it to 2.x; it will be
some time until refpolicy uses 2.x version numbers and by then the
policy module will be worthless anyway.
That way, if we'd e.g. have to do a security update for the policy
package, this customized module wouldn't be updated.
I don't think there is a big cost in replacing modules with the exact
same version (they'll be processed anyway; AFAIK we don't modify the
compiled policy, but instead it's assembled again from the .pp files?)
At least not if you do all the processing in one step; doing a single
semodule -i call of course isn't cheap.
So please use the version numbers in the modules.
> Hmm. I had not thought about blacklisting modules. I think, if
> you have a local module that overrides a refpolicy module, and so you
> don't want to have the module changed at all, it should be easy enough
> to implement a configuration file which sets a blacklist variable.
And it would be a very easy to understand behavior, nicer than the
version numbers. But I still wouldn't skip the version checking.
best regards,
Erich Schubert
--=20
erich@(vitavonni.de|debian.org) -- GPG Key ID: 4B3A135C (o_
Reality continues to ruin my life --- Calvin //\
Die k=C3=BCrzeste Verbindung zwischen zwei Menschen ist ein L=C3=A4che=
ln. V_/_
| |
| Manoj Srivastava 2007-05-09, 1:22 am |
| On Wed, 09 May 2007 02:34:18 +0200, Erich Schubert <erich@debian.org> said:
> Hello Manoj,
> Well, that script actually is shell.
Err, I can read. The guts of the magic was, as you say, in python.
> The Python script is what I use to do the autodetection magic.
[vbcol=seagreen]
> I don't think this is a good idea. If I have (for whatever reason) to
> modify a policy module, I'd like to be able to bump the version number
> a bit to avoid it from being updated.
OK. Given a .pp file, how _do_ you detect what version it is?
manoj
--
"Don't think; let the machine do it for you!" Berkeley
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Gabor Gombas 2007-05-09, 7:23 am |
| On Wed, May 09, 2007 at 02:34:18AM +0200, Erich Schubert wrote:
> I don't think this is a good idea. If I have (for whatever reason) to
> modify a policy module, I'd like to be able to bump the version number a
> bit to avoid it from being updated. Like bumping it to 2.x; it will be
> some time until refpolicy uses 2.x version numbers and by then the
> policy module will be worthless anyway.
> That way, if we'd e.g. have to do a security update for the policy
> package, this customized module wouldn't be updated.
Well, I don't know much about SElinux (yet) but how about storing the
modified module at a different location (say under
/var/selinux/local-policy)? That way the update script can be taught to
simply ignore the shipped module if a customized module with the same
name exists, and use your customized version instead. No need to play
with version numbers, no need to check if the file was changed.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2007-05-09, 1:23 pm |
| On Wed, 9 May 2007 13:00:14 +0200, Gabor Gombas <gombasg@sztaki.hu> said:
> Well, I don't know much about SElinux (yet) but how about storing the
> modified module at a different location (say under
> /var/selinux/local-policy)? That way the update script can be taught
> to simply ignore the shipped module if a customized module with the
> same name exists, and use your customized version instead. No need to
> play with version numbers, no need to check if the file was changed.
Sure. The problem is when your policy .deb is upgraded, and the
postinst tries to refresh the installed policy (perhaps asking using
debconf to ask you). At this point, I know how to look up the version
of the policy module foo that is installed (and is also present in
/etc/selinux/<policy-type>/modules/active/modules/foo.pp). But I do not
know the version of /usr/share/selinux/<policy-type>/foo.pp.
I can, of course, determine that these two files are different
/etc/selinux/<policy-type>/modules/active/modules/foo.pp and
/usr/share/selinux/<policy-type>/foo.pp -- but Ercih wants me to be
version aware, and that is the problem.
I am not sure I can see how we can easily change the location of
the policy store ( /etc/selinux/<policy-type>/modules/active/modules),
if you think the store location should be changed.
manoj
--
"If you are patient in one moment of anger, you will escape a hundred
days of sorrow." -Chinese Proverb
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russell Coker 2007-05-21, 7:22 am |
| On Wednesday 09 May 2007 10:34, Erich Schubert <erich@debian.org> wrote:
>
> Yep, I'm generating them on compile time in my packages and storing them
> in an auxillary file. shipping another 1k file with the package felt
> nicer to me than computing it on install time.
That's fine as long as the dependencies don't change due to local
modifications.
>
> I don't think this is a good idea. If I have (for whatever reason) to
> modify a policy module, I'd like to be able to bump the version number a
> bit to avoid it from being updated. Like bumping it to 2.x; it will be
> some time until refpolicy uses 2.x version numbers and by then the
> policy module will be worthless anyway.
To have this work well we would need to have more formality in the version
numbers than currently exists.
We need to determine which parts of the version can be changed by which people
(upstream, distribution packaging, and local changes), and in what situations
they change (incompatibility, security fixes, and general changes).
--
russell@coker.com.au
http://etbe.coker.com.au/ My Blog
http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
|
|
| Erich Schubert 2007-05-21, 1:20 pm |
| Hello Neil,
[vbcol=seagreen]
> How would that method cope with a cross-build? Emdebian has already
> built some selinux packages from the Debian sources for a rootfs and
We're talking about policy package dependencies, not about debian
package dependencies. These dependencies mean that the foobar.pp policy
package can't be installed unless quux.pp is also installed.
If you want to change that for Emdebian, you'll be building a different
policy, and then you can just include a different dependency file with
that policy. Now refpolicy is already very tight on permissions; I don't
think you'll really want to further narrow down permissions for Emdebian
(though you e.g. could put PERL into a separate domain and then prevent
some domains from executing perl... right now, any process that can
run /usr/bin/less can also run /usr/bin/perl)
best regards,
Erich Schubert
--
erich@(vitavonni.de|debian.org) -- GPG Key ID: 4B3A135C (o_
Reality continues to ruin my life --- Calvin //\
Mathematik: Das Alphabet, mit dessen Hilfe Gott das Universum V_/_
beschrieben hat. --- Galileo Galilei
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Neil Williams 2007-05-21, 1:20 pm |
| On Mon, 21 May 2007 14:56:49 +0200
Erich Schubert <erich@debian.org> wrote:
> Hello Neil,
>
>
> We're talking about policy package dependencies, not about debian
> package dependencies.
Oops. Sorry.
> These dependencies mean that the foobar.pp policy
> package can't be installed unless quux.pp is also installed.
> If you want to change that for Emdebian, you'll be building a different
> policy, and then you can just include a different dependency file with
> that policy. Now refpolicy is already very tight on permissions; I don't
> think you'll really want to further narrow down permissions for Emdebian
> (though you e.g. could put PERL into a separate domain and then prevent
> some domains from executing perl... right now, any process that can
> run /usr/bin/less can also run /usr/bin/perl)
Thanks for the clarification.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
| |
| Russell Coker 2007-05-22, 7:19 am |
| On Monday 21 May 2007 22:56, Erich Schubert <erich@debian.org> wrote:
>
> We're talking about policy package dependencies, not about debian
> package dependencies. These dependencies mean that the foobar.pp policy
> package can't be installed unless quux.pp is also installed.
> If you want to change that for Emdebian, you'll be building a different
> policy, and then you can just include a different dependency file with
> that policy. Now refpolicy is already very tight on permissions; I don't
> think you'll really want to further narrow down permissions for Emdebian
> (though you e.g. could put PERL into a separate domain and then prevent
> some domains from executing perl... right now, any process that can
> run /usr/bin/less can also run /usr/bin/perl)
The strict policy is by design quite restrictive. In many cases where there
are multiple ways of configuring things the policy allows for several options
and thus is larger than necessary.
For an embedded system running on a known platform you should be able to
remove a lot of policy without any problems, maybe half the volume of the
policy or more.
http://www.coker.com.au/selinux/talks/ols2003/
Also for an embedded platform you have to deal with busybox and related
optimisations. My paper at the above URL describes some possible solutions
to this problem.
--
russell@coker.com.au
http://etbe.coker.com.au/ My Blog
http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|