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
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.
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
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.
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
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
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
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
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.
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
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
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
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.
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
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
selinux@lists.fedoraproject.org
-
Joshua Brindle -
Mike Hearn -
Stephen Smalley