I know its way late but I'd like to add a new SELinux concept to the F9 kernels. Its going to be a backport of a couple of my changesets headed upstream
http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdi... http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdi... http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdi...
Only the third patch is truly interesting.
A permissive domain is a new concept in which a sysadmin can say that a given domain is free to do anything it wants. Lets say a user seriously customized httpd and they want httpd to just be allowed to run wild while still keeping enforcing for everything else in the system. With the kernel patch I want to commit and the userspace changes dan has already pushed this week they just need a simple policy which says "permissive httpd_t" and all their httpd_t denials become allows!
One of the upstream patches adds a BUG_ON() but I'm still a teensy bit scared of it so in the F9 patch I'll probably make it a WARN_ON since it isn't really deadly to the kernel... anyway. Chances of regression here are very very low.
I would just jam this in myself but we are getting really late and I wanted people to be able to tell me no before I did it. If noone strongly objects quickly expect to see a commit message early this week....
-Eric
On Mon, Mar 31, 2008 at 02:07:44PM -0400, Eric Paris wrote:
I know its way late but I'd like to add a new SELinux concept to the F9 kernels. Its going to be a backport of a couple of my changesets headed upstream
http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdi... http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdi... http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdi...
Only the third patch is truly interesting.
A permissive domain is a new concept in which a sysadmin can say that a given domain is free to do anything it wants. Lets say a user seriously customized httpd and they want httpd to just be allowed to run wild while still keeping enforcing for everything else in the system. With the kernel patch I want to commit and the userspace changes dan has already pushed this week they just need a simple policy which says "permissive httpd_t" and all their httpd_t denials become allows!
One of the upstream patches adds a BUG_ON() but I'm still a teensy bit scared of it so in the F9 patch I'll probably make it a WARN_ON since it isn't really deadly to the kernel... anyway. Chances of regression here are very very low.
I would just jam this in myself but we are getting really late and I wanted people to be able to tell me no before I did it. If noone strongly objects quickly expect to see a commit message early this week....
It is indeed, very late. I'm concerned by just how much busted stuff we have[*], so shovelling in more features after the feature freeze is making me wince. From a quick look at the patches, this is a fairly small amount of code that's changing, that looks harmless.
What userspace changes are necessary for this? Are they in place already? We'll pick this up anyway in 2-3 months as an F9 update when we rebase to 2.6.26, so I guess the userspace bits will have to be done at some point, but I'd rather we spent effort beating what we have already into shape than forward planning right now.
(That said, selinux is pretty solid from a kernel pov. Still some warts in policy, but Dan is nailing those pretty quickly as usual).
I dunno.
Dave
[*] The top kerneloops.org regressions right now are all in code that's been added to Fedora that isn't upstream (yet). This is not a good sign.
On Mon, 2008-03-31 at 14:24 -0400, Dave Jones wrote:
It is indeed, very late. I'm concerned by just how much busted stuff we have[*], so shovelling in more features after the feature freeze is making me wince. From a quick look at the patches, this is a fairly small amount of code that's changing, that looks harmless.
What userspace changes are necessary for this? Are they in place already?
Dan already committed/build the changes to the libsepol library http://koji.fedoraproject.org/koji/buildinfo?buildID=44062
and then checkpolicy must be patched and rebuilt after the new library makes it into the build root since checkpolicy uses static linking with libsepol.
We'll pick this up anyway in 2-3 months as an F9 update when we rebase to 2.6.26, so I guess the userspace bits will have to be done at some point, but I'd rather we spent effort beating what we have already into shape than forward planning right now.
I want to see usability get to users as fast as I can. If others object we will get it in for free in the future, but I know improving selinux usability is a big deal for this, users have wanted to see such an options and wanted to get others opinion for committing.
-Eric
On Mon, 2008-03-31 at 14:07 -0400, Eric Paris wrote:
I know its way late but I'd like to add a new SELinux concept to the F9 kernels. Its going to be a backport of a couple of my changesets headed upstream
http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdi... http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdi...
The second patch is effectively a bug fix, as otherwise open(2) with flags 3 will fail ever since the dentry_open hook was added. So that one makes sense regardless of the permissive domains patches.
http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdi...
Only the third patch is truly interesting.
A permissive domain is a new concept in which a sysadmin can say that a given domain is free to do anything it wants. Lets say a user seriously customized httpd and they want httpd to just be allowed to run wild while still keeping enforcing for everything else in the system. With the kernel patch I want to commit and the userspace changes dan has already pushed this week they just need a simple policy which says "permissive httpd_t" and all their httpd_t denials become allows!
One of the upstream patches adds a BUG_ON() but I'm still a teensy bit scared of it so in the F9 patch I'll probably make it a WARN_ON since it isn't really deadly to the kernel... anyway. Chances of regression here are very very low.
I would just jam this in myself but we are getting really late and I wanted people to be able to tell me no before I did it. If noone strongly objects quickly expect to see a commit message early this week....
On Mon, 2008-03-31 at 14:07 -0400, Eric Paris wrote:
I know its way late but I'd like to add a new SELinux concept to the F9 kernels. Its going to be a backport of a couple of my changesets headed upstream
As a cranky release engineering person, no no no no no no
We have a feature freeze for a reason, the kernel doesn't get a blank check to get past it. If it was that important, it would have been done in time for the freeze. The next release is in six months, so it's not like it's that long to have to wait
Jeremy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jeremy Katz wrote:
On Mon, 2008-03-31 at 14:07 -0400, Eric Paris wrote:
I know its way late but I'd like to add a new SELinux concept to the F9 kernels. Its going to be a backport of a couple of my changesets headed upstream
As a cranky release engineering person, no no no no no no
We have a feature freeze for a reason, the kernel doesn't get a blank check to get past it. If it was that important, it would have been done in time for the freeze. The next release is in six months, so it's not like it's that long to have to wait
Jeremy
I can go either way whether this goes in or not. The userspace updates are done, The only change would be to modify some tools to quickly build a policy module to make a domain permissive.
Permissive domains is a great new feature though:
If gives users the following:
1. Some Wall Street customers originally brought up the idea. They want to be able to build a policy package to confine an application and after testing destribute it to their systems as a permissive domain. Then run it for a couple of months, once they are convinced that it will not break anything, they can turn it to an enforcing domain. We could start doing similar things for new confined domains in Rawhide. 2. We have a regression reported against Fedora since Fedora 7 that complained when we removed *disable_trans booleans. These were removed because disabling a transition in one domain could effect another domain by not setting the file context correctly. So permissive domains would be a great replacement for disable_trans. 3 Finally when a user builds a new policy for a domain, we tell them to use tools to build a framework for policy and install the new domain and setup labeling. Then we tell them to put the machine in permissive mode to run the app, and gather AVCs. This change would allow you to leave your entire machine in enforcing mode while you run your new domain in permissive mode, gathering the AVCs. 4. Some times people are convinced SELinux is causing a application to break, one way we tell them to test whether SELinux is the culprit is put the machine in permissive mode and see if the app still breaks, permissive domains would give us the ability to only put one domain in permissive mode.
On Tue, 2008-04-01 at 06:42 +0200, Daniel J Walsh wrote:
Jeremy Katz wrote:
On Mon, 2008-03-31 at 14:07 -0400, Eric Paris wrote:
I know its way late but I'd like to add a new SELinux concept to the F9 kernels. Its going to be a backport of a couple of my changesets headed upstream
As a cranky release engineering person, no no no no no no
We have a feature freeze for a reason, the kernel doesn't get a blank check to get past it. If it was that important, it would have been done in time for the freeze. The next release is in six months, so it's not like it's that long to have to wait
I can go either way whether this goes in or not. The userspace updates are done, The only change would be to modify some tools to quickly build a policy module to make a domain permissive.
Permissive domains is a great new feature though:
Yes, and it'll still be a great new feature for Fedora 10. We have deadlines. When we don't stick to them, they lead to releases slippage.
Jeremy
On Tue, 2008-04-01 at 10:50 -0400, Jeremy Katz wrote:
On Tue, 2008-04-01 at 06:42 +0200, Daniel J Walsh wrote:
Jeremy Katz wrote:
On Mon, 2008-03-31 at 14:07 -0400, Eric Paris wrote:
I know its way late but I'd like to add a new SELinux concept to the F9 kernels. Its going to be a backport of a couple of my changesets headed upstream
As a cranky release engineering person, no no no no no no
We have a feature freeze for a reason, the kernel doesn't get a blank check to get past it. If it was that important, it would have been done in time for the freeze. The next release is in six months, so it's not like it's that long to have to wait
I can go either way whether this goes in or not. The userspace updates are done, The only change would be to modify some tools to quickly build a policy module to make a domain permissive.
Permissive domains is a great new feature though:
Yes, and it'll still be a great new feature for Fedora 10. We have deadlines. When we don't stick to them, they lead to releases slippage.
Well Dan unless you cover his eyes when I do the commit I guess we'll get this when F9 pulls the next kernel from linus :(
-Eric
kernel@lists.fedoraproject.org