From the message titled 'Fedora Core 2 and SELinux'
SELinux *will* be included in Fedora Core 2 test 3 and the final Fedora Core 2 release. However, SELinux will be disabled by default. To install with SELinux support, pass 'selinux' to the installer on the command line. (Or, configure it appropriately in kickstart).
Why are we using the command line option to install SELinux process. I provided to the SEL list, a comp.xml skeleton that I used to add SEL to Core 1. In the original framework I just added dependencies that were not on the std Linux install (i.e. sharutils). A follow through to this could provide a separate selection within the group for policy tools and source to allow the installer to put the source in place as well (as shown in the category section below)
<group> <id>selinux</id> <uservisible>true</uservisible> <default>true</default> <name>SELinux Installation</name> <description>Install this group of packages to configure the system for SELinux installation.</description> <grouplist> </grouplist> <packagelist> <packagereq type="mandatory">sharutils</packagereq> <packagereq type="mandatory">linuxdoc-tools</packagereq> <packagereq type="mandatory">netpbm-progs</packagereq> <packagereq type="mandatory">tetex-latex</packagereq> <packagereq type="mandatory">autoconf213</packagereq> <packagereq type="mandatory">elfutils-devel</packagereq> <packagereq type="mandatory">libcroco-devel</packagereq> </packagelist> </group>
<category> <name>SELinux</name> <subcategories> <subcategory>selinux</subcategory> <subcategory>policy tools/source</subcategory> </subcategories> </category>
On Wed, 2004-04-28 at 21:16 -0500, Nick wrote:
Why are we using the command line option to install SELinux process. I provided to the SEL list, a comp.xml skeleton that I used to add SEL to Core 1.
The option has nothing to do with what packages get installed, it deals instead with if we set up such things as xattrs on the filesystem and whether policy will end up loading by default.
Jeremy
On Wed, 2004-04-28 at 21:43, Jeremy Katz wrote:
On Wed, 2004-04-28 at 21:16 -0500, Nick wrote:
Why are we using the command line option to install SELinux process. I provided to the SEL list, a comp.xml skeleton that I used to add SEL to Core 1.
The option has nothing to do with what packages get installed, it deals instead with if we set up such things as xattrs on the filesystem and whether policy will end up loading by default
Isn't all of that via packages?
Isn't the kernel build during install from a source package?
So your saying that the switch is just a way of setting the level that is currently set in the firewall screen of the install?
What about building a core 2 system without SELinux. Are we forcing users to use SEL if they are using Fedora in the future?
Jeremy
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Wed, 2004-04-28 at 22:06 -0500, Nick Gray wrote:
On Wed, 2004-04-28 at 21:43, Jeremy Katz wrote:
On Wed, 2004-04-28 at 21:16 -0500, Nick wrote:
Why are we using the command line option to install SELinux process. I provided to the SEL list, a comp.xml skeleton that I used to add SEL to Core 1.
The option has nothing to do with what packages get installed, it deals instead with if we set up such things as xattrs on the filesystem and whether policy will end up loading by default
Isn't all of that via packages?
It's based on information in packages, but it's influenced also by _how_ the packages are installed. Not by which packages are actually being installed. ie, what %__file_context_path is set to for RPM and thus whether contexts are set on files as they're laid down on the filesystem. Also, what ends up in /etc/sysconfig/selinux which gets looked at by init to determine whether policy should be loaded or not.
Isn't the kernel build during install from a source package?
Ummm, no. This would a) require the installation of a compiler and b) make the install time much longer, especially on older hardware.
So your saying that the switch is just a way of setting the level that is currently set in the firewall screen of the install?
Whether or not the control is even shown. SELinux is not at this point something that is going to be suitable for all users -- this will change over time, but right now avoiding having the users who don't know better from getting into trouble is a good idea just to cut down on the support burden.
What about building a core 2 system without SELinux. Are we forcing users to use SEL if they are using Fedora in the future?
No, there's nothing that forces you to use SELinux. There are things that depend on libselinux, but that doesn't mean that you're actually using SELinux.
Jeremy
On Thu, 2004-04-29 at 10:05, Jeremy Katz wrote:
On Wed, 2004-04-28 at 22:06 -0500, Nick Gray wrote:
On Wed, 2004-04-28 at 21:43, Jeremy Katz wrote:
On Wed, 2004-04-28 at 21:16 -0500, Nick wrote:
Why are we using the command line option to install SELinux process. I provided to the SEL list, a comp.xml skeleton that I used to add SEL to Core 1.
The option has nothing to do with what packages get installed, it deals instead with if we set up such things as xattrs on the filesystem and whether policy will end up loading by default
Isn't all of that via packages?
It's based on information in packages, but it's influenced also by _how_ the packages are installed. Not by which packages are actually being installed. ie, what %__file_context_path is set to for RPM and thus whether contexts are set on files as they're laid down on the filesystem. Also, what ends up in /etc/sysconfig/selinux which gets looked at by init to determine whether policy should be loaded or not.
This seems like semantics, you won't need to set xattrs, setup a /selinux directory, or access any of the selinux packages if you are given the option not to install SEL.
My original point addresses an issue with the switch setting. I believe that the switch is the wrong way to implement this
Isn't the kernel build during install from a source package?
Ummm, no. This would a) require the installation of a compiler and b) make the install time much longer, especially on older hardware.
I vaguely recall this. So the default kernels must be pretty large to contain all of the modules, etc, for each option (Bluetooth etc.. ).
So your saying that the switch is just a way of setting the level that is currently set in the firewall screen of the install?
Whether or not the control is even shown. SELinux is not at this point something that is going to be suitable for all users -- this will change over time, but right now avoiding having the users who don't know better from getting into trouble is a good idea just to cut down on the support burden.
I still think you are missing my point. Is the SELinux kernel installed by default and directories such as '/etc/security' created even if the switch is off?
Assuming for the moment that selecting the switch during the install, prevents any trace of SEL from showing on the system, why do it via switch? Why not use the installation menu and leave the SELinux portion disabled by default?
Making the other assumption that all the binaries/directories are installed, and just not enabled. I think those of us who need to have this accredited are going to have a tough time with the distinction of installed but not used. The selection should let you go down one of two paths, installed or not installed. The distinction needs to be pristine if those of us who need this for secure implementations are going to present it
What about building a core 2 system without SELinux. Are we forcing users to use SEL if they are using Fedora in the future?
No, there's nothing that forces you to use SELinux. There are things that depend on libselinux, but that doesn't mean that you're actually using SELinux.
See above
Jeremy
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Thu, 2004-04-29 at 10:05, Jeremy Katz wrote:
On Wed, 2004-04-28 at 22:06 -0500, Nick Gray wrote:
On Wed, 2004-04-28 at 21:43, Jeremy Katz wrote:
On Wed, 2004-04-28 at 21:16 -0500, Nick wrote:
Why are we using the command line option to install SELinux process. I provided to the SEL list, a comp.xml skeleton that I used to add SEL to Core 1.
The option has nothing to do with what packages get installed, it deals instead with if we set up such things as xattrs on the filesystem and whether policy will end up loading by default
Isn't all of that via packages?
It's based on information in packages, but it's influenced also by _how_ the packages are installed. Not by which packages are actually being installed. ie, what %__file_context_path is set to for RPM and thus whether contexts are set on files as they're laid down on the filesystem. Also, what ends up in /etc/sysconfig/selinux which gets looked at by init to determine whether policy should be loaded or not.
This seems like semantics, you won't need to set xattrs, setup a /selinux directory, or access any of the selinux packages if you are given the option not to install SEL.
My original point addresses an issue with the switch setting. I believe that the switch is the wrong way to implement this
Isn't the kernel build during install from a source package?
Ummm, no. This would a) require the installation of a compiler and b) make the install time much longer, especially on older hardware.
I vaguely recall this. So the default kernels must be pretty large to contain all of the modules, etc, for each option (Bluetooth etc.. ).
So your saying that the switch is just a way of setting the level that is currently set in the firewall screen of the install?
Whether or not the control is even shown. SELinux is not at this point something that is going to be suitable for all users -- this will change over time, but right now avoiding having the users who don't know better from getting into trouble is a good idea just to cut down on the support burden.
I still think you are missing my point. Is the SELinux kernel installed by default and directories such as '/etc/security' created even if the switch is off?
Assuming for the moment that selecting the switch during the install, prevents any trace of SEL from showing on the system, why do it via switch? Why not use the installation menu and leave the SELinux portion disabled by default?
Making the other assumption that all the binaries/directories are installed, and just not enabled. I think those of us who need to have this accredited are going to have a tough time with the distinction of installed but not used. The selection should let you go down one of two paths, installed or not installed. The distinction needs to be pristine if those of us who need this for secure implementations are going to present it
What about building a core 2 system without SELinux. Are we forcing users to use SEL if they are using Fedora in the future?
No, there's nothing that forces you to use SELinux. There are things that depend on libselinux, but that doesn't mean that you're actually using SELinux.
See above
Jeremy
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Thu, 2004-04-29 at 11:35 -0500, Nick wrote:
On Thu, 2004-04-29 at 10:05, Jeremy Katz wrote:
On Wed, 2004-04-28 at 22:06 -0500, Nick Gray wrote:
On Wed, 2004-04-28 at 21:43, Jeremy Katz wrote:
On Wed, 2004-04-28 at 21:16 -0500, Nick wrote:
Why are we using the command line option to install SELinux process. I provided to the SEL list, a comp.xml skeleton that I used to add SEL to Core 1.
The option has nothing to do with what packages get installed, it deals instead with if we set up such things as xattrs on the filesystem and whether policy will end up loading by default
Isn't all of that via packages?
It's based on information in packages, but it's influenced also by _how_ the packages are installed. Not by which packages are actually being installed. ie, what %__file_context_path is set to for RPM and thus whether contexts are set on files as they're laid down on the filesystem. Also, what ends up in /etc/sysconfig/selinux which gets looked at by init to determine whether policy should be loaded or not.
This seems like semantics, you won't need to set xattrs, setup a /selinux directory, or access any of the selinux packages if you are given the option not to install SEL.
But you *have* to install some SELinux packages. eg, libselinux is always going to end up being installed due to dependencies of other packages. And doing an 'Everything' install (although I hate them) also shouldn't necessarily imply that you want SELinux enabled and setup.
Isn't the kernel build during install from a source package?
Ummm, no. This would a) require the installation of a compiler and b) make the install time much longer, especially on older hardware.
I vaguely recall this. So the default kernels must be pretty large to contain all of the modules, etc, for each option (Bluetooth etc.. ).
Yes, the kernel package is not small and contains many, many modules.
So your saying that the switch is just a way of setting the level that is currently set in the firewall screen of the install?
Whether or not the control is even shown. SELinux is not at this point something that is going to be suitable for all users -- this will change over time, but right now avoiding having the users who don't know better from getting into trouble is a good idea just to cut down on the support burden.
I still think you are missing my point. Is the SELinux kernel installed by default and directories such as '/etc/security' created even if the switch is off?
The kernel includes the support and the directories are created, but without policy being loaded, etc, there isn't an impact. Okay, that's not 100% true. There was a performance hit due to some additional hooks being added, but with recent kernel changes, you can unregister on the fly and so init will now do that if it's not loading a policy and thus mitigate that.
Assuming for the moment that selecting the switch during the install, prevents any trace of SEL from showing on the system, why do it via switch? Why not use the installation menu and leave the SELinux portion disabled by default?
Because there's not a way to give enough information on what all of the ramifications are. And with the current state of things, it's thus best to make it an option for people who know what they're doing.
Making the other assumption that all the binaries/directories are installed, and just not enabled. I think those of us who need to have this accredited are going to have a tough time with the distinction of installed but not used. The selection should let you go down one of two paths, installed or not installed. The distinction needs to be pristine if those of us who need this for secure implementations are going to present it
It's not that hard. Take a look at is_selinux_enabled() in libselinux for the way to determine this. And even that's not even enough if you're wanting to make some sort of "guarantee" on the security of the system -- what your policy is directly defines this. SELinux itself is just a framework to provide the capability for having a secure implementation.
Jeremy
Jeremy Katz wrote:
But you *have* to install some SELinux packages. eg, libselinux is always going to end up being installed due to dependencies of other packages.
Incidentally Fedora 1 has a similar situation. If you want Postgres, you have to install krb5-libs, even if you aren't using Kerberos. If you are going to ship binary packages, you have to turn on all the options that anyone could want. I guess taken to extremes it would increase bloat unacceptably, but krb5-libs and the user space SELinux libraries are not large.
Because there's not a way to give enough information on what all of the ramifications are [of installing SELinux]. And with the current state of things, it's thus best to make it an option for people who know what they're doing.
I think this is especially true for a new security technology. Most people's view of security is quite simplistic: they want the bad guys kept out, without their work being interfered with. If SELinux interferes with their work, they will turn it off, reasoning that normal Unix security has kept the bad guys out so far. They are then unlikely to try it again later however much people tell them that the policy has been improved.
Pete
On Fri, 2004-04-30 at 05:40, Pete Chown wrote:
I think this is especially true for a new security technology. Most people's view of security is quite simplistic: they want the bad guys kept out, without their work being interfered with. If SELinux interferes with their work, they will turn it off, reasoning that normal Unix security has kept the bad guys out so far. They are then unlikely to try it again later however much people tell them that the policy has been improved.
So how would people feel about a separate relaxed policy that allows everything in the system to run completely unconfined except for a small set of specific services, e.g. apache, bind, postfix, ... That would ensure that SELinux wouldn't get in the way of users, while providing some protection benefit for network-facing services.
On Fri, 2004-04-30 at 08:34 -0400, Stephen Smalley wrote:
So how would people feel about a separate relaxed policy that allows everything in the system to run completely unconfined except for a small set of specific services, e.g. apache, bind, postfix, ... That would ensure that SELinux wouldn't get in the way of users, while providing some protection benefit for network-facing services.
I think (consistent with my view a few months ago :-) that this is a very good idea. At the same time, it's something that's clearly not realistic to target for FC2 since the last test release just went out and so it'd be going out with very little testing.
Jeremy
On Fri, 2004-04-30 at 09:24, Jeremy Katz wrote:
I think (consistent with my view a few months ago :-) that this is a very good idea. At the same time, it's something that's clearly not realistic to target for FC2 since the last test release just went out and so it'd be going out with very little testing.
That's fine; it can always be introduced post-FC2. It matters little for FC2 given that SELinux will be disabled by default for it anyway.
On Fri, Apr 30, 2004 at 10:03:51AM -0400, Stephen Smalley wrote:
On Fri, 2004-04-30 at 09:24, Jeremy Katz wrote:
I think (consistent with my view a few months ago :-) that this is a very good idea. At the same time, it's something that's clearly not realistic to target for FC2 since the last test release just went out and so it'd be going out with very little testing.
That's fine; it can always be introduced post-FC2. It matters little for FC2 given that SELinux will be disabled by default for it anyway.
Yes a small focused policy is a good thing and much better than apparently inviting people to boot with SELinux off.
This would keep the security checking code paths active, but with a minimum list of things to check the impact would be minimized. This includes syslog noise as well.
A minimized policy would remove much demand to remove or hobble the kernel side mechanism and minimize any divergence that developers might wish to introduce.
I happen to like the current effort to "classify everything" but this is a big task. Since not all packages that folks like to use pass through RH hands the task is almost unbounded.
On Fri, Apr 30, 2004 at 08:34:44AM -0400, Stephen Smalley wrote:
So how would people feel about a separate relaxed policy that allows everything in the system to run completely unconfined except for a small set of specific services, e.g. apache, bind, postfix, ... That would ensure that SELinux wouldn't get in the way of users, while providing some protection benefit for network-facing services.
While I think that a relaxed policy might be useful to server admins who would rather not fix their admin scripts, etc., the full policy ought not be terribly burdensome on a dedicated server.
It is on the desktop that SELinux potentially offers the greatest benefit and the greatest burden. Client apps (and particularly GUI client apps) -- browser, e-mail, IM, media players, will be targeted. We laugh at poor MS Outlook users, but social engineering works. A measurable fraction of Linux users will inevitably read their e-mail and follow that link, look at that picture or video clip, play that game applet, etc. It is the client apps that need confinement.
While exploiting a client app doesn't immediately give the attacker admin privileges, that's largely irrelevant if the purpose of the attack is to (1) harvest, destroy, or modify the user's data, or (2) use the client at a zombie for some purpose.
Confining Postfix and not Mozilla is like double-locking the front door, but leaving the bathroom window open.
Regards,
Bill Rugolsky
On Fri, 2004-04-30 at 09:33, Bill Rugolsky Jr. wrote:
While I think that a relaxed policy might be useful to server admins who would rather not fix their admin scripts, etc., the full policy ought not be terribly burdensome on a dedicated server.
It is on the desktop that SELinux potentially offers the greatest benefit and the greatest burden. Client apps (and particularly GUI client apps) -- browser, e-mail, IM, media players, will be targeted. We laugh at poor MS Outlook users, but social engineering works. A measurable fraction of Linux users will inevitably read their e-mail and follow that link, look at that picture or video clip, play that game applet, etc. It is the client apps that need confinement.
While exploiting a client app doesn't immediately give the attacker admin privileges, that's largely irrelevant if the purpose of the attack is to (1) harvest, destroy, or modify the user's data, or (2) use the client at a zombie for some purpose.
Confining Postfix and not Mozilla is like double-locking the front door, but leaving the bathroom window open.
And yet the default tunable settings in the Fedora policy effectively undo much of the benefit of the example mozilla policy (see 'readhome' and 'writehome'). Yes, you can change those tunable settings. But offering a separate relaxed policy doesn't mean that you can no longer choose a strict policy; it just means that the relaxed policy can be greatly simplified (as you can collapse many domains and types together), will be much easier to get right (thus avoiding users disabling SELinux entirely), and won't keep "leaking" weakness into the strict policy. It also makes the choice clear to users.
SELinux provides flexible support for security policies in recognition of the fact that a single policy won't meet everyone's desires or needs. Forcing everyone to use a single security policy (even a single policy with small variations via tunables) runs counter to the point, and seems to be leading to SELinux disabled by default. That will ultimately lead to ever greater divergence and compatibility issues between the SELinux-enabled state and the SELinux-disabled state, effectively yielding two different systems like the old trusted vs. mainstream product separation of old. Better to have SELinux enabled all the time with two different policies that are appropriately tuned to the needs and desires of differing user communities.
On Fri, Apr 30, 2004 at 10:02:32AM -0400, Stephen Smalley wrote:
Better to have SELinux enabled all the time with two different policies that are appropriately tuned to the needs and desires of differing user communities.
I concur with that sentiment, and didn't mean to imply that a relaxed policy is not desirable. Not having to frantically rebuild a server app the moment an exploit is discovered is reason enough to have SELinux confining all network-facing servers. I only wanted to highlight that expectations need to be reset as both the default policy has been loosened, and the relaxed policy will loosen things further. I would hate for it to reflect negatively on SELinux when someone exploits an FC2 default SELinux install; the press will not make fine distinctions, and there will be gloating from other corners. Toward that end, I think it is important that users understand where along the "low-medium-high" spectrum they have set their security.
Having SELinux on by default, even with a relatively permissive policy, will (1) ensure that the code is exercised, and (2) force developers, packagers, etc., to think about the required logic, and address any performance problems, so we can get to a more secure default install.
Regards,
Bill Rugolsky
On Fri, 2004-04-30 at 10:39 -0400, Bill Rugolsky Jr. wrote:
I concur with that sentiment, and didn't mean to imply that a relaxed policy is not desirable. Not having to frantically rebuild a server app the moment an exploit is discovered is reason enough to have SELinux confining all network-facing servers. I only wanted to highlight that expectations need to be reset as both the default policy has been loosened, and the relaxed policy will loosen things further. I would hate for it to reflect negatively on SELinux when someone exploits an FC2 default SELinux install; the press will not make fine distinctions, and there will be gloating from other corners. Toward that end, I think it is important that users understand where along the "low-medium-high" spectrum they have set their security.
Definitely -- my plan is to provide the spectrum of choices and also have accompanying explanatory text so that users can make an informed decision about what they want to use SELinux-wise on their system
Having SELinux on by default, even with a relatively permissive policy, will (1) ensure that the code is exercised, and (2) force developers, packagers, etc., to think about the required logic, and address any performance problems, so we can get to a more secure default install.
Yep, and hopefully then in the longer term, we can move to more and more locked down setups as users become used to the concepts introduced by SELinux and applications become aware of it.
Jeremy
On Fri, 30 Apr 2004, Bill Rugolsky Jr. wrote:
and the relaxed policy will loosen things further. I would hate for it to reflect negatively on SELinux when someone exploits an FC2 default SELinux install; the press will not make fine distinctions, and there will be gloating from other corners.
I think we need to concentrate on what will actually increase overall security in the long term.
- James
On Fri, 2004-04-30 at 10:39, Bill Rugolsky Jr. wrote:
I concur with that sentiment, and didn't mean to imply that a relaxed policy is not desirable. Not having to frantically rebuild a server app the moment an exploit is discovered is reason enough to have SELinux confining all network-facing servers. I only wanted to highlight that expectations need to be reset as both the default policy has been loosened, and the relaxed policy will loosen things further. I would hate for it to reflect negatively on SELinux when someone exploits an FC2 default SELinux install; the press will not make fine distinctions, and there will be gloating from other corners. Toward that end, I think it is important that users understand where along the "low-medium-high" spectrum they have set their security.
One thing to consider is that the "relaxed" policy may actually end up being more "secure" for the set of security goals it targets. Perhaps a better term than "relaxed" would be "specialized" or "targeted". Given a small focused set of security goals, you can more easily specify the policy and analyze it for exceptions. In contrast, when you try to put every process in its own sandbox while supporting existing functionality (particularly functionality that isn't used to living in sandboxes), it becomes very difficult to analyze the resulting large, complex policy to see whether it meets your higher level goals (e.g. don't let apache subvert a trusted process).
On Fri, Apr 30, 2004 at 12:14:08PM -0400, Stephen Smalley wrote:
One thing to consider is that the "relaxed" policy may actually end up being more "secure" for the set of security goals it targets. Perhaps a better term than "relaxed" would be "specialized" or "targeted". Given a small focused set of security goals, you can more easily specify the policy and analyze it for exceptions. In contrast, when you try to put every process in its own sandbox while supporting existing functionality (particularly functionality that isn't used to living in sandboxes), it becomes very difficult to analyze the resulting large, complex policy to see whether it meets your higher level goals (e.g. don't let apache subvert a trusted process).
This sounds like a very good approach, and is much less threatening to a sysadmin with a large base of systems and users that are all basically working fine now.
On Fri, 30 Apr 2004 10:02:32 EDT, Stephen Smalley sds@epoch.ncsc.mil said:
SELinux provides flexible support for security policies in recognition of the fact that a single policy won't meet everyone's desires or needs.
Just in case my previous note was unclear - I actually agree with Stephen. If I'm reading his proposal correctly, it *is* something that will be of use in some environments - it's just that my needs are going in other directions. (Similarl to the fact there's a need for an Oracle-class database system, even though I don't run any of those either)...
Stephen Smalley wrote:
So how would people feel about a separate relaxed policy that allows everything in the system to run completely unconfined except for a small set of specific services, e.g. apache, bind, postfix, ...
This sounds like a big change of direction, but I think it would be useful for servers. It would also be a good starting point for people developing their own policies.
It might also be good to introduce SELinux gradually, taking the easy security gains first. It's comparatively easy to isolate things like Apache, so one approach would be to take that improvement while continuing to work on the rest.
Has anyone attempted to add type enforcement to a commercial desktop operating system before? I haven't heard of it being done; as far as I know the various distros' SELinux projects are breaking new ground. That is probably one reason why it is turning up more problems than expected.
Pete
On Fri, 2004-04-30 at 13:34, Stephen Smalley wrote:
So how would people feel about a separate relaxed policy that allows everything in the system to run completely unconfined except for a small set of specific services, e.g. apache, bind, postfix, ... That would ensure that SELinux wouldn't get in the way of users, while providing some protection benefit for network-facing services.
I think that would be very worthwhile, and would probably speed uptake of SELinux on Fedora.
I for one would happily switch that on asap and then gradually move to something more secure when it was much more polished.
Cheers,
Martin.
On Fri, 30 Apr 2004 08:34:44 EDT, Stephen Smalley sds@epoch.ncsc.mil said:
So how would people feel about a separate relaxed policy that allows everything in the system to run completely unconfined except for a small set of specific services, e.g. apache, bind, postfix, ... That would ensure that SELinux wouldn't get in the way of users, while providing some protection benefit for network-facing services.
Hmm.. that sounds like something that might be a good idea for some environments, but it's not something that I want on my machines.
Personally, I *like* the idea that things like Mozilla and my MUA can be confined - my machines are already hardened enough that those two are positively the soft underbelly of the system....
On Fri, 30 Apr 2004, Stephen Smalley wrote:
On Fri, 2004-04-30 at 05:40, Pete Chown wrote:
I think this is especially true for a new security technology. Most people's view of security is quite simplistic: they want the bad guys kept out, without their work being interfered with. If SELinux interferes with their work, they will turn it off, reasoning that normal Unix security has kept the bad guys out so far. They are then unlikely to try it again later however much people tell them that the policy has been improved.
So how would people feel about a separate relaxed policy that allows everything in the system to run completely unconfined except for a small set of specific services, e.g. apache, bind, postfix, ... That would ensure that SELinux wouldn't get in the way of users, while providing some protection benefit for network-facing services.
My initial reaction is that it sounds like quitting smoking by each month reducing by one the number of cigarettes smoked per day. You are certainly headed in the right direction, but taking a god awful amount of time getting there. Who knows what will happen in the meantime.
Cold turkey sounds good. Nice, secure defaults, with the option to turn it off temporarily during testing would give us the chance to shake out the bugs the quickest. I would advocate having a range of security selections available. I will certainly avail myself of the opportunity to test the strictest of those choices, consistent with getting a little work done. I want good policy available, and awareness/pressure on developers to consider policy when creating applications.
Stephen Smalley wrote:
On Fri, 2004-04-30 at 05:40, Pete Chown wrote:
I think this is especially true for a new security technology. Most people's view of security is quite simplistic: they want the bad guys kept out, without their work being interfered with. If SELinux interferes with their work, they will turn it off, reasoning that normal Unix security has kept the bad guys out so far. They are then unlikely to try it again later however much people tell them that the policy has been improved.
So how would people feel about a separate relaxed policy that allows everything in the system to run completely unconfined except for a small set of specific services, e.g. apache, bind, postfix, ... That would ensure that SELinux wouldn't get in the way of users, while providing some protection benefit for network-facing services.
Another separate example policy would be very good. Additional different example policies would 1) demonstrate the flexibility on the concept and mechanism and 2) provide usage information that would useful in designing a better 'language' or higher level of abstraction. If there is an improved 'language', implementation and usage would be facilitated. Richard Hally
On Wed, 2004-04-28 at 21:43, Jeremy Katz wrote:
On Wed, 2004-04-28 at 21:16 -0500, Nick wrote:
Why are we using the command line option to install SELinux process. I provided to the SEL list, a comp.xml skeleton that I used to add SEL to Core 1.
The option has nothing to do with what packages get installed, it deals instead with if we set up such things as xattrs on the filesystem and whether policy will end up loading by default
Isn't all of that via packages?
Isn't the kernel build during install from a source package?
So your saying that the switch is just a way of setting the level that is currently set in the firewall screen of the install?
What about building a core 2 system without SELinux. Are we forcing users to use SEL if they are using Fedora in the future?
Jeremy
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
selinux@lists.fedoraproject.org