Re: Sid SELinux packages are now working
On Monday 21 May 2007 22:56, Erich Schubert [EMAIL PROTECTED] wrote: 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) 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. -- [EMAIL PROTECTED] http://etbe.coker.com.au/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sid SELinux packages are now working
On Wednesday 09 May 2007 10:34, Erich Schubert [EMAIL PROTECTED] wrote: 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. 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 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. 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). -- [EMAIL PROTECTED] http://etbe.coker.com.au/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sid SELinux packages are now working
On Mon, 21 May 2007 19:08:34 +1000 Russell Coker [EMAIL PROTECTED] wrote: On Wednesday 09 May 2007 10:34, Erich Schubert [EMAIL PROTECTED] wrote: 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. 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. How would that method cope with a cross-build? Emdebian has already built some selinux packages from the Debian sources for a rootfs and various dependency changes have and will continue to be necessary. As far as a rootfs is concerned, Emdebian has already removed perl from our version of 'Essential' and changes to glibc are likely too (splitting the package). http://www.emdebian.org/packages/search.php?package=libselinux1distro=unstablearch=arm http://www.emdebian.org/ http://wiki.debian.org/EmdebianRootfs http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/19-Smaller-libc6.html -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp9ElEiBPSbt.pgp Description: PGP signature
Re: Sid SELinux packages are now working
Hello Neil, 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. 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 UniversumV_/_ beschrieben hat. --- Galileo Galilei -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sid SELinux packages are now working
On Mon, 21 May 2007 14:56:49 +0200 Erich Schubert [EMAIL PROTECTED] wrote: Hello Neil, 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. 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. 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/ pgpCe1ZJgs4dt.pgp Description: PGP signature
Re: Sid SELinux packages are now working
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [DSE-Dev] Re: Sid SELinux packages are now working
Hi, OK. Given a .pp file, how _do_ you detect what version it is? For installed modules, we can just use semodule -l I havn't tried it, but there is semanage.semanage_module_get_version in the python semanage bindings. I don't know if this only works for installed modules or for packages. But I'd suggest to add an option to semodule like --stat or so that we can use to query the version number of a .pp file. That should be doable. best regards, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ To be trusted is a greater complement than to be loved. //\ Nur der ist weise, der weiß, dass er es nicht ist. --- Sokrates V_/_
Re: Sid SELinux packages are now working
On Wed, 9 May 2007 13:00:14 +0200, Gabor Gombas [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Sid SELinux packages are now working
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 [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sid SELinux packages are now working
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/refpolicy/branches/debian-pkg/debian/utils/update-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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sid SELinux packages are now working
On Wed, 09 May 2007 00:09:12 +0200, Erich Schubert [EMAIL PROTECTED] said: 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/refpolicy/branches/debian-pkg/debian/utils/update-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 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. 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 [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sid SELinux packages are now working
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, so 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 -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ Reality continues to ruin my life --- Calvin//\ Die kürzeste Verbindung zwischen zwei Menschen ist ein Lächeln. V_/_
Re: Sid SELinux packages are now working
On Wed, 09 May 2007 02:34:18 +0200, Erich Schubert [EMAIL PROTECTED] said: Hello Manoj, Hmm. Python. I think I looked at that when I implemented the 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. 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. 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 [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
