Hi, everyone. I'm sending this email as a result of a discussion in the Fedora QA meeting this morning. You can find a log of the meeting here:
http://meetbot.fedoraproject.org/fedora-meeting/2009-11-23/fedora-meeting.20...
the discussion takes place from 16:14:09 onwards.
We discussed the recent PackageKit kerfuffle from a QA perspective, which means we talked about how we could have meaningful security testing. We came to some basic conclusions about this which require co-ordination with the security and development groups.
We can't do any meaningful security testing without knowing exactly what we should be testing for, in which packages. I believe Seth Vidal's upcoming proposal for covering 'major changes' may touch on this, but I doubt they'll cover exactly the same ground.
So, if we are to have meaningful security testing in future releases - which QA believes would be a good thing - we need the project to define a security policy. We believe there's a genuine need for this anyway, as the introduction and widespread adoption of PolicyKit will likely lead to much more complex and significant potential changes in security posture than any previous change.
It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here.
The second thing QA would require, aside from a policy with concrete and testable requirements, is a list of security-sensitive components to test. Obviously we couldn't test every package in the entire distribution for compliance with even such a simple list as spot's, and it would be a waste of time to try.
Focussing on the relatively simple issues for now, we believe it would be reasonably simple to generate a list of all packages in the distribution that attempt privilege escalation. We believe this would be a list of packages that contain suid binaries, that invoke su, sudo or consolehelper, or that contain PolicyKit policies. This list of packages would be what the QA team would test with regard to the security policy. We also believe there ought to be a process for maintaining this list, and additions to the packaging guidelines for any new package which would be on this list or any existing package for which a proposed change would add it to this list. We could also hook AutoQA into this process, to run additional tests on security-sensitive packages or alert us when a package change was submitted which added security-sensitive elements to an existing package.
Will Woods has indicated he is prepared to help work on the tools necessary to generate the security-sensitive package list. The QA group as a whole is happy to contribute what input we can to any discussion of a general security policy. Mostly, we wanted to make it clear that we believe security testing would be of benefit to the distribution, but these things need to be in place before any meaningful such testing could be done.
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote:
This list of packages would be what the QA team would test with regard to the security policy. We also believe there ought to be a process for maintaining this list, and additions to the packaging guidelines for any new package which would be on this list or any existing package for which a proposed change would add it to this list. We could also hook AutoQA into this process, to run additional tests on security-sensitive packages or alert us when a package change was submitted which added security-sensitive elements to an existing package.
I would warn against trying to have a manual static list of packages here, same as crit-path. These packages need to be discoverable via software.
On Mon, 2009-11-23 at 14:33 -0800, Jesse Keating wrote:
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote:
This list of packages would be what the QA team would test with regard to the security policy. We also believe there ought to be a process for maintaining this list, and additions to the packaging guidelines for any new package which would be on this list or any existing package for which a proposed change would add it to this list. We could also hook AutoQA into this process, to run additional tests on security-sensitive packages or alert us when a package change was submitted which added security-sensitive elements to an existing package.
I would warn against trying to have a manual static list of packages here, same as crit-path. These packages need to be discoverable via software.
yeah, sorry - I was thinking along the same lines, having a script to generate the list. I thought that was kind of implied in what I wrote but I guess not :)
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote:
It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here.
I don't think spots list is too useful, unfortunately; discussing an abstract 'unprivileged user' without defining some roles and use cases doesn't make much sense to me. There is probably a difference between a guest account and a regular (non-admin) user in what I want them to be able to do; 'unprivileged user' does not allow that distinction. And there is certainly a difference between what a regular user is expected to be allowed on a family computer vs a university computer lab.
On Mon, 23 Nov 2009, Matthias Clasen wrote:
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote:
It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here.
I don't think spots list is too useful, unfortunately; discussing an abstract 'unprivileged user' without defining some roles and use cases doesn't make much sense to me. There is probably a difference between a guest account and a regular (non-admin) user in what I want them to be able to do; 'unprivileged user' does not allow that distinction. And there is certainly a difference between what a regular user is expected to be allowed on a family computer vs a university computer lab.
And this is why spot's list is useful.
A family computer and a university computer lab have a lot in common but where they diverge we should start with err toward MORE restrictive and allow configuration by the local admin/owner to LESS restrictive.
Otherwise we open ourselves up to a less-secure-by-default posture in an average install.
We've been in that position in the past and it is not a favorable place to be.
-sv
On Mon, 2009-11-23 at 18:31 -0500, Seth Vidal wrote:
Otherwise we open ourselves up to a less-secure-by-default posture in an average install.
We've been in that position in the past and it is not a favorable place to be.
We should just avoid to sink tons of QA resources in verifying that a theoretical 'unprivileged user' can do nothing, when that role is not something anybody would want to use anyway (because it can do nothing) and is not the role that most users will actually end up with in a typical desktop install.
On Mon, 23 Nov 2009, Matthias Clasen wrote:
On Mon, 2009-11-23 at 18:31 -0500, Seth Vidal wrote:
Otherwise we open ourselves up to a less-secure-by-default posture in an average install.
We've been in that position in the past and it is not a favorable place to be.
We should just avoid to sink tons of QA resources in verifying that a theoretical 'unprivileged user' can do nothing, when that role is not something anybody would want to use anyway (because it can do nothing) and is not the role that most users will actually end up with in a typical desktop install.
If someone installing/deploying fedora (or a fedora-derived spin) wants to configure a specific user or a set of users to have greater power, then they should be able to do that.
The default as shipped in our packages should not empower users significantly.
Default strict, configure relaxed.
-sv
On Mon, 2009-11-23 at 19:36 -0500, Seth Vidal wrote:
On Mon, 23 Nov 2009, Matthias Clasen wrote:
On Mon, 2009-11-23 at 18:31 -0500, Seth Vidal wrote:
Otherwise we open ourselves up to a less-secure-by-default posture in an average install.
We've been in that position in the past and it is not a favorable place to be.
We should just avoid to sink tons of QA resources in verifying that a theoretical 'unprivileged user' can do nothing, when that role is not something anybody would want to use anyway (because it can do nothing) and is not the role that most users will actually end up with in a typical desktop install.
If someone installing/deploying fedora (or a fedora-derived spin) wants to configure a specific user or a set of users to have greater power, then they should be able to do that.
The default as shipped in our packages should not empower users significantly.
Default strict, configure relaxed.
I don't want to ship a desktop that doesn't let the user do useful things.
How that translates in packages and defaults is not really the most important part, but the plan is to have strict package defaults + a policy package that makes things work.
The important part is that we QA the combination, not just the strict defaults.
On Mon, 23 Nov 2009, Matthias Clasen wrote:
I don't want to ship a desktop that doesn't let the user do useful things.
And you can ship a desktop SPIN that way. But the base pkgs should not install with an insecure set of choices.
if you want the spin to have a post-scriptlet which allows more things, then that's the choice of the desktop sig over the desktop spin.
We should not be forcing the choices for the desktop spin on everyone who installs a pkg in the distribution.
-sv
* [2009-11-23 19:54:11 -0500] Seth Vidal wrote:
On Mon, 23 Nov 2009, Matthias Clasen wrote:
I don't want to ship a desktop that doesn't let the user do useful things.
And you can ship a desktop SPIN that way. But the base pkgs should not install with an insecure set of choices.
if you want the spin to have a post-scriptlet which allows more things, then that's the choice of the desktop sig over the desktop spin.
We should not be forcing the choices for the desktop spin on everyone who installs a pkg in the distribution.
The base system should always be more restrictive and secure. How hard is it to have Anaconda ask the user what their typical use-case is? Home computer, single-user, relax some stuff, install policy A. Home computer, multi-user? Policy B. Fort Knox? Policy X.
But these customizations should come post-install, customized via Anaconda or a package that installs a policy set or something with the idea that base packages should always have the lowest common denominator which really has to be ideal security. Not saying it needs to go to extremes so the user needs to enter a password to wiggle the mouse, but there should be some good reasonable secure defaults.
And the user should pretty much have to choose to be less secure. Don't make them choose to be _more_ secure. I don't think anyone will gripe if they have to check off an extra box to relax system security, but they're gonna be quite annoyed (as we've seen) if we take away responsible security practices in the name of convenience.
I don't want to ship a desktop that doesn't let the user do useful things.
And you can ship a desktop SPIN that way. But the base pkgs should not install with an insecure set of choices.
if you want the spin to have a post-scriptlet which allows more things, then that's the choice of the desktop sig over the desktop spin.
Given how .pkla works, this is likely to be done with packages, not with %post hackery. (Which should make it much easier to reliably test, as well.)
Bill
On Tue, 24 Nov 2009, Bill Nottingham wrote:
I don't want to ship a desktop that doesn't let the user do useful things.
And you can ship a desktop SPIN that way. But the base pkgs should not install with an insecure set of choices.
if you want the spin to have a post-scriptlet which allows more things, then that's the choice of the desktop sig over the desktop spin.
Given how .pkla works, this is likely to be done with packages, not with %post hackery. (Which should make it much easier to reliably test, as well.)
provided those pkgs are not required anywhere or set in our default pkg groups, then sure.
-sv
On Tue, 2009-11-24 at 13:28 -0500, Bill Nottingham wrote:
I don't want to ship a desktop that doesn't let the user do useful things.
And you can ship a desktop SPIN that way. But the base pkgs should not install with an insecure set of choices.
if you want the spin to have a post-scriptlet which allows more things, then that's the choice of the desktop sig over the desktop spin.
Given how .pkla works, this is likely to be done with packages, not with %post hackery. (Which should make it much easier to reliably test, as well.)
As I noted somewhat flippantly in another thread, this comes with the problem that, theoretically, a user who has the privileges to install packages at a relaxed security level could arbitrarily raise the security level of the system to a much higher level, against the wishes of the administrator.
perhaps something akin to system-config-selinux would be needed to guard against this? I'm not sure how it could work in the PolicyKit framework, though.
On Tue, 2009-11-24 at 10:44 -0800, Adam Williamson wrote:
As I noted somewhat flippantly in another thread, this comes with the problem that, theoretically, a user who has the privileges to install packages at a relaxed security level could arbitrarily raise the security level of the system to a much higher level, against the wishes of the administrator.
perhaps something akin to system-config-selinux would be needed to guard against this? I'm not sure how it could work in the PolicyKit framework, though.
or, I suppose more trivially, a PackageKit policy for the ability to install PolicyKit policy packages. heh, now that's a bizarre sentence.
On Mon, 2009-11-23 at 19:38 -0500, Matthias Clasen wrote:
How that translates in packages and defaults is not really the most important part, but the plan is to have strict package defaults + a policy package that makes things work.
The important part is that we QA the combination, not just the strict defaults.
Right. If the Grand Plan is to go down this path, then what I've been referring to as 'the security policy' would include the policies defined for each spin, and hence any testing QA did for any given spin would involve the policy defined for that spin.
Having said that - is everyone agreeing that it's fine for each spin SIG to be entirely in charge of defining and implementing security policy for each spin? At the very least, that would possibly be problematic given the known border issues between 'the desktop spin' and 'Fedora'. Just another issue contributing to why we would need to settle that.
On Mon, 2009-11-23 at 18:10 -0800, Adam Williamson wrote:
On Mon, 2009-11-23 at 19:38 -0500, Matthias Clasen wrote:
How that translates in packages and defaults is not really the most important part, but the plan is to have strict package defaults + a policy package that makes things work.
The important part is that we QA the combination, not just the strict defaults.
Right. If the Grand Plan is to go down this path, then what I've been referring to as 'the security policy' would include the policies defined for each spin, and hence any testing QA did for any given spin would involve the policy defined for that spin.
Having said that - is everyone agreeing that it's fine for each spin SIG to be entirely in charge of defining and implementing security policy for each spin? At the very least, that would possibly be problematic given the known border issues between 'the desktop spin' and 'Fedora'. Just another issue contributing to why we would need to settle that.
Honestly, leaving PackageKit wide open would only make sense. All operating systems that I'm aware of generally install open and require the end user to shore up their own installation because from the engineer's point of view they want the operating system to work on everyone's computer so they do things like leave the firewall wide open and allow you to login to ssh as root. Of course being able to flip a couple of switches to shut that down is more than appropriate.
I'm not saying that I agree with this open policy, however. Many people don't know that they should do anything to secure their computers from install. It's also a pain to harden these systems after each install. I've often thought about doing a spin for those of us that use Fedora within the U.S. Government or U.S. Military that would be pre-hardened and ready to go. Just install and go. It would pass NIST and DISA controls from the get go.
While that would also be great for home users it might be a bit overkill (or maybe not). If Fedora (and every other operating system) wants to make a change in security posture the hardening script similar to the one that comes with MySQL would be a great place to start. The user would install the software and go through the standard installation stuff and then would be presented by a little icon on their desktop that when selected would ask them simple questions that would automagically harden their system depending on the answers. Would be a heck of a lot better than going through the NSA's RHEL Hardening Guide (which is an awesome text, by the way).
Just my 2 cents worth.
--Eric
On Mon, Nov 23, 2009 at 06:10:59PM -0800, Adam Williamson wrote:
On Mon, 2009-11-23 at 19:38 -0500, Matthias Clasen wrote:
How that translates in packages and defaults is not really the most important part, but the plan is to have strict package defaults + a policy package that makes things work.
The important part is that we QA the combination, not just the strict defaults.
Right. If the Grand Plan is to go down this path, then what I've been referring to as 'the security policy' would include the policies defined for each spin, and hence any testing QA did for any given spin would involve the policy defined for that spin.
Having said that - is everyone agreeing that it's fine for each spin SIG to be entirely in charge of defining and implementing security policy for each spin? At the very least, that would possibly be problematic given the known border issues between 'the desktop spin' and 'Fedora'. Just another issue contributing to why we would need to settle that.
I'm very much against that. Fedora, Linux, and Unix-like operating systems have built a reputation as a more secure alternative to Windows and other operating systems. We have to have some level of security that comes enabled on all systems no matter what the spin.
Also, conflating "Fedora" with the "Desktop Spin" is something I'm very uncomfortable with here. A spin meant to highlight what the authors think is the most convenient experience for a single user desktop system apparently wants to do things that I am not at all for highlighting as the default Fedora environment. We need to separate these so that the Desktop Spin can live its own life without the additional constraints of being Fedora.
-Toshio
On Mon, 2009-11-23 at 17:55 -0500, Matthias Clasen wrote:
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote:
It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here.
I don't think spots list is too useful, unfortunately; discussing an abstract 'unprivileged user' without defining some roles and use cases doesn't make much sense to me. There is probably a difference between a guest account and a regular (non-admin) user in what I want them to be able to do; 'unprivileged user' does not allow that distinction. And there is certainly a difference between what a regular user is expected to be allowed on a family computer vs a university computer lab.
Sure, I don't disagree, but I think we can take spots list and use it for the 'guest account'. Then you start picking things off the list as you move up the stack to 'university computer lab user (is that really much different from guest?)', to 'non-admin user', to 'admin user'.
Although I have read all of the messages on this thread as of the date/time of this message, I am replying to this first message with all of my comments.
My background: I am currently retired but a few years ago I was still being paid the big bucks for working on computer security and security assessment of systems in US classified environments.
On the whole, I believe that Adam has outlined a good approach to the problem of doing QA on security for Fedora!
General comment: I have read messages which claim that the approach is wrong and that we need to look at things that a user can do rather than what a user cannot do. I disagree. While the right approach for design/development is to assume that a user can do nothing except what they are specifically authorized to do, for security QA this needs to be turned around and the testing needs to demonstrate what a user cannot do.
On Monday 23 November 2009 17:08:31 Adam Williamson wrote:
We can't do any meaningful security testing without knowing exactly what we should be testing for, in which packages. I believe Seth Vidal's upcoming proposal for covering 'major changes' may touch on this, but I doubt they'll cover exactly the same ground.
So, if we are to have meaningful security testing in future releases - which QA believes would be a good thing - we need the project to define a security policy. We believe there's a genuine need for this anyway, as the introduction and widespread adoption of PolicyKit will likely lead to much more complex and significant potential changes in security posture than any previous change.
It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here.
+1
A written description of the security policy is a must! Without it being written down in simple english (with translations as appropriate), there will be far too much subjective interpretation of what the policy is. I believe spot's list is a good starting point for F13.
However, the policy should consider how Fedora should work with respect to security and not how it does work as currently implemented. For example, you cannot currently login as root from the gui (gdm) interface but you can login as root from a virtual terminal ... is this the way the system should work?
Keep it simple (KISS) for the initial attempt. It will grow more complicated all by itself as time passes.
BTW, the security policy should assume that a grub password is in use so that a user cannot do something like disabling selinux by editing the kernel command line. This should be tested by the security QA.
The second thing QA would require, aside from a policy with concrete and testable requirements, is a list of security-sensitive components to test. Obviously we couldn't test every package in the entire distribution for compliance with even such a simple list as spot's, and it would be a waste of time to try.
+1
You definitely need to define a "reference implementation" that will be tested. Security assurance testing is done on "as-built" systems ... not "as designed"! It may be possible but is not practical to test everything. [or will take so long that the release will no longer be supported]
Furthermore, I believe you should initially focus on a small subset of what is in Fedora (perhaps gnome only) and with a selected set of services (servers).
At this point in time, considering all of the various windows implementations (gnome, kde, openbox, xfce, etc.) will result in a lot of motion but little of it in a forward direction. KISS!!!
........... Given a written security policy for Fedora and a written description of the "reference implementation" that will be tested, these need to be vetted and "tuned" from comments.
After a reasonable amount of time, these documents/specifications should be approved by the Fedora Executive Committee (or whatever). Any variation or change, should require additional approval. There should be some independent oversight of the security QA process to minimize subjective (re)interpretation.
This will NOT make everyone happy. Sorry, but there is only so much resources and you really do not want this to be a black hole which consumes everything else.
Start small, grow, and learn. Two years from now, the security policy, the reference installation/configurations, and the QA process for securtiy will likely be very different.
Gene
On Mon, Nov 30, 2009 at 15:09, Gene Czarcinski gene@czarc.net wrote:
Although I have read all of the messages on this thread as of the date/time of this message, I am replying to this first message with all of my comments.
My background: I am currently retired but a few years ago I was still being paid the big bucks for working on computer security and security assessment of systems in US classified environments.
On the whole, I believe that Adam has outlined a good approach to the problem of doing QA on security for Fedora!
General comment: I have read messages which claim that the approach is wrong and that we need to look at things that a user can do rather than what a user cannot do. I disagree. While the right approach for design/development is to assume that a user can do nothing except what they are specifically authorized to do, for security QA this needs to be turned around and the testing needs to demonstrate what a user cannot do.
On Monday 23 November 2009 17:08:31 Adam Williamson wrote:
We can't do any meaningful security testing without knowing exactly what we should be testing for, in which packages. I believe Seth Vidal's upcoming proposal for covering 'major changes' may touch on this, but I doubt they'll cover exactly the same ground.
So, if we are to have meaningful security testing in future releases - which QA believes would be a good thing - we need the project to define a security policy. We believe there's a genuine need for this anyway, as the introduction and widespread adoption of PolicyKit will likely lead to much more complex and significant potential changes in security posture than any previous change.
It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here.
+1
A written description of the security policy is a must! Without it being written down in simple english (with translations as appropriate), there will be far too much subjective interpretation of what the policy is. I believe spot's list is a good starting point for F13.
However, the policy should consider how Fedora should work with respect to security and not how it does work as currently implemented. For example, you cannot currently login as root from the gui (gdm) interface but you can login as root from a virtual terminal ... is this the way the system should work?
Keep it simple (KISS) for the initial attempt. It will grow more complicated all by itself as time passes.
BTW, the security policy should assume that a grub password is in use so that a user cannot do something like disabling selinux by editing the kernel command line. This should be tested by the security QA.
The second thing QA would require, aside from a policy with concrete and testable requirements, is a list of security-sensitive components to test. Obviously we couldn't test every package in the entire distribution for compliance with even such a simple list as spot's, and it would be a waste of time to try.
+1
You definitely need to define a "reference implementation" that will be tested. Security assurance testing is done on "as-built" systems ... not "as designed"! It may be possible but is not practical to test everything. [or will take so long that the release will no longer be supported]
Furthermore, I believe you should initially focus on a small subset of what is in Fedora (perhaps gnome only) and with a selected set of services (servers).
At this point in time, considering all of the various windows implementations (gnome, kde, openbox, xfce, etc.) will result in a lot of motion but little of it in a forward direction. KISS!!!
........... Given a written security policy for Fedora and a written description of the "reference implementation" that will be tested, these need to be vetted and "tuned" from comments.
After a reasonable amount of time, these documents/specifications should be approved by the Fedora Executive Committee (or whatever). Any variation or change, should require additional approval. There should be some independent oversight of the security QA process to minimize subjective (re)interpretation.
This will NOT make everyone happy. Sorry, but there is only so much resources and you really do not want this to be a black hole which consumes everything else.
Start small, grow, and learn. Two years from now, the security policy, the reference installation/configurations, and the QA process for securtiy will likely be very different.
Gene
Gene, (Ahh... someone with a similar background...)
So the biggest question, to me, is to what standard do we start? There are plenty to choose from from DISA to NIST. I, personally, find the NSA's "Guide to the Secure Configuration of Red Hat Enterprise Linux 5" very good and might be a good place to start. I'm not saying that we do everything that is in the guide but maybe take the guide and strike things out that don't make sense and add stuff to it that does make sense.
Thoughts?
--Eric
On Mon, 2009-11-30 at 15:17 -0500, Eric Christensen wrote:
Gene, (Ahh... someone with a similar background...)
So the biggest question, to me, is to what standard do we start? There are plenty to choose from from DISA to NIST. I, personally, find the NSA's "Guide to the Secure Configuration of Red Hat Enterprise Linux 5" very good and might be a good place to start. I'm not saying that we do everything that is in the guide but maybe take the guide and strike things out that don't make sense and add stuff to it that does make sense.
Thanks for the thoughts, Gene and Eric. You seem to be running a long way ahead here :). I should probably say that I think I mistitled the thread: what I was really thinking about here is not 'security', but the more limited area of 'privilege escalation'. I'm not sure we're ready to bite off a comprehensive distro-wide security policy yet, to the extent you two are discussing.
Where I'm currently at is that I'm going to talk to some Red Hat / Fedora security folks about the issues raised in all the discussions about this, including this thread, and then file a ticket to ask FESco to look at the matter, possibly including a proposed policy if the security folks help come up with one. And for the moment, only really concerned with the question of privileges.
On Monday 30 November 2009 18:16:50 Adam Williamson wrote:
On Mon, 2009-11-30 at 15:17 -0500, Eric Christensen wrote:
Gene, (Ahh... someone with a similar background...)
So the biggest question, to me, is to what standard do we start? There are plenty to choose from from DISA to NIST. I, personally, find the NSA's "Guide to the Secure Configuration of Red Hat Enterprise Linux 5" very good and might be a good place to start. I'm not saying that we do everything that is in the guide but maybe take the guide and strike things out that don't make sense and add stuff to it that does make sense.
Thanks for the thoughts, Gene and Eric. You seem to be running a long way ahead here :). I should probably say that I think I mistitled the thread: what I was really thinking about here is not 'security', but the more limited area of 'privilege escalation'. I'm not sure we're ready to bite off a comprehensive distro-wide security policy yet, to the extent you two are discussing.
But, you did say the right words for what is needed to do security QA and not just privilege escalation.
Where I'm currently at is that I'm going to talk to some Red Hat / Fedora security folks about the issues raised in all the discussions about this, including this thread, and then file a ticket to ask FESco to look at the matter, possibly including a proposed policy if the security folks help come up with one. And for the moment, only really concerned with the question of privileges.
Start small with just privilege escalation and it can be grown to be something more comprehensive. FESco is the right place to go and see what the project wants to do.
I suspect that most commercial and government customers will be interested in Red Hat Enterprise Linux rather than Fedora. But, Fedora is the technology base on which future Red Hat Enterprise Linux releases are built. The better Fedora is, the more confidence customers will have the the Red Hat product.
Gene
On Tue, Dec 1, 2009 at 12:47, Gene Czarcinski gene@czarc.net wrote:
On Monday 30 November 2009 18:16:50 Adam Williamson wrote:
Where I'm currently at is that I'm going to talk to some Red Hat / Fedora security folks about the issues raised in all the discussions about this, including this thread, and then file a ticket to ask FESco to look at the matter, possibly including a proposed policy if the security folks help come up with one. And for the moment, only really concerned with the question of privileges.
Start small with just privilege escalation and it can be grown to be something more comprehensive. FESco is the right place to go and see what the project wants to do.
There is already a security policy in place. It's not formalized nor is it written down but it's there. It's the current posture of Fedora. We set a root passphrase at the beginning of install and we give people the option of securing GRUB with a passphrase and encrypting the hard drive. We also have the unwritten rule of user privileges.
It may be time to document our current posture to at least show where we are and the standard we expect all developers to live up to. In the process of documenting you may find that we are lacking somewhere.
--Eric
On Tuesday 01 December 2009 13:04:02 Eric Christensen wrote:
On Tue, Dec 1, 2009 at 12:47, Gene Czarcinski gene@czarc.net wrote:
On Monday 30 November 2009 18:16:50 Adam Williamson wrote:
Where I'm currently at is that I'm going to talk to some Red Hat /
Fedora security folks about the issues raised in all the discussions about this, including this thread, and then file a ticket to ask FESco to look at the matter, possibly including a proposed policy if the security folks help come up with one. And for the moment, only really concerned with the question of privileges.
Start small with just privilege escalation and it can be grown to be something more comprehensive. FESco is the right place to go and see what the project wants to do.
There is already a security policy in place. It's not formalized nor is it written down but it's there. It's the current posture of Fedora. We set a root passphrase at the beginning of install and we give people the option of securing GRUB with a passphrase and encrypting the hard drive. We also have the unwritten rule of user privileges.
It may be time to document our current posture to at least show where we are and the standard we expect all developers to live up to. In the process of documenting you may find that we are lacking somewhere.
Yes, there has always been a security policy as defined by the written code (software). But, that is subject to individual interpretation. I agree that creating a written security policy is likely to identify shortcomings such as my point about the GRUB password.
Lots of folks who use computers clearly do not understand the underlying technology and are clearly not paranoid enough. Given a home computer, do you really want your teenager installing file-sharing software. Recently, the US Congress discovered that some of their users had installed file-sharing software --- and the result was not positive.
Fedora needs to provide good functionality while keeping our collective sanity ... we need software which is not just easy to use but is smarter about how it is used.
Gene
On Tue, 2009-12-01 at 12:47 -0500, Gene Czarcinski wrote:
I suspect that most commercial and government customers will be interested in Red Hat Enterprise Linux rather than Fedora. But, Fedora is the technology base on which future Red Hat Enterprise Linux releases are built. The better Fedora is, the more confidence customers will have the the Red Hat product.
I agree. What I'm really worried about here, ultimately, is PolicyKit, and the way it permits a lot more grey areas than have been possible before. If you look at previous privilege escalation mechanisms, they're simplistic; whether you're using sudo or consolehelper or whatever, ultimately you either have a process run as root or as user. And it's pretty obvious what should run as root and what shouldn't; I don't remember there being any real serious debates about that, everyone pretty much reaches the same conclusions independently. The authentication question is equally simple: basically either the process just runs as root automatically (which everyone agrees should happen for as few processes as possible), or you have to authenticate each time - for Fedora, basically you have to type the root password, since we never really used sudo.
Things like 'well, we can perform this one specific type of operation with this one specific type of authentication' just weren't possible. Now they are, so stuff like the PackageKit issue was bound to start happening. The things PolicyKit make possible really need some kind of coherent oversight, I think, and that is indeed something Red Hat Enterprise Linux will also need to address, so obviously from an RH perspective, it helps RH if Fedora develops some kind of policy for this. But I think it's necessary for Fedora anyway, regardless of RH.
On Tuesday 01 December 2009 13:56:51 Adam Williamson wrote:
On Tue, 2009-12-01 at 12:47 -0500, Gene Czarcinski wrote:
I suspect that most commercial and government customers will be interested in Red Hat Enterprise Linux rather than Fedora. But, Fedora is the technology base on which future Red Hat Enterprise Linux releases are built. The better Fedora is, the more confidence customers will have the the Red Hat product.
I agree. What I'm really worried about here, ultimately, is PolicyKit, and the way it permits a lot more grey areas than have been possible before. If you look at previous privilege escalation mechanisms, they're simplistic; whether you're using sudo or consolehelper or whatever, ultimately you either have a process run as root or as user. And it's pretty obvious what should run as root and what shouldn't; I don't remember there being any real serious debates about that, everyone pretty much reaches the same conclusions independently. The authentication question is equally simple: basically either the process just runs as root automatically (which everyone agrees should happen for as few processes as possible), or you have to authenticate each time - for Fedora, basically you have to type the root password, since we never really used sudo.
Things like 'well, we can perform this one specific type of operation with this one specific type of authentication' just weren't possible. Now they are, so stuff like the PackageKit issue was bound to start happening. The things PolicyKit make possible really need some kind of coherent oversight, I think, and that is indeed something Red Hat Enterprise Linux will also need to address, so obviously from an RH perspective, it helps RH if Fedora develops some kind of policy for this. But I think it's necessary for Fedora anyway, regardless of RH.
What you are saying put more emphasis on getting a security policy written and ratified by FESco. And you will also need some oversight of what the developers are doing with respect to security and this security policy. The QA process should catch the "oops" problems ... not those done intentionally by a well-intentioned developer.
I do not know that much about PolicyKit and given my interests in security, I probably need to learn about it. One thing that occurs to me is to wonder if PolicyKit is using SELinux (see SELinux Users and Roles). If not, why not?
Regardless of how PolicyKit works, the default should be locked-down with an easy-to-use sysadmin tool to provide configuration with the ability to open- things-up in a controlled manner.
You should talk to the folks handling SELinux. My impression of them is that they know what they are doing and may provide some insight into the PolicyKit "problem".
Fedora has come a long way since SELinux was first introduced. It would be a shame if the enhanced security provided by SELinux was negated by PolicyKit.
A couple of other comments:
- No, I do not believe that regular users should be able to update or install software globally without transitioning to an admin role ... they can put stuff in their home directory but not globally.
- I agree with Smooge in one of the messages he wrote ... there are many users who would like to run Fedora just like Windows95. That may be but that does not mean that Fedora should follow that idea.
Gene
Gene Czarcinski (gene@czarc.net) said:
Keep it simple (KISS) for the initial attempt. It will grow more complicated all by itself as time passes.
BTW, the security policy should assume that a grub password is in use so that a user cannot do something like disabling selinux by editing the kernel command line. This should be tested by the security QA.
That seems very broken. A security policy that is violated on every single out of the box install that doesn't do customization?
Bill
On Monday 30 November 2009 15:43:26 Bill Nottingham wrote:
Gene Czarcinski (gene@czarc.net) said:
Keep it simple (KISS) for the initial attempt. It will grow more complicated all by itself as time passes.
BTW, the security policy should assume that a grub password is in use so that a user cannot do something like disabling selinux by editing the kernel command line. This should be tested by the security QA.
That seems very broken. A security policy that is violated on every single out of the box install that doesn't do customization?
Agreed ... it is broken.
As I see it, the problem is that without a grub password, then an un- privileged user can edit the command line to disable selinux or bootup in single user mode.
On the other hand, there is also "good enough" versus perfect. In a perfect world, a user would (by default) be required to enter that password. In a "good enough" world, have the option to set the password.
A "split the difference" (better) world (this is a change from existing implementation): have the grub password default to being root's password.
[I have not tested this in install but I assume that root's password cannot be null.]
I do not want to see the goal for Fedora to be perfect ... simply "good enough".
Gene
On Mon, Nov 30, 2009 at 16:39:05 -0500, Gene Czarcinski gene@czarc.net wrote:
As I see it, the problem is that without a grub password, then an un- privileged user can edit the command line to disable selinux or bootup in single user mode.
On the other hand, there is also "good enough" versus perfect. In a perfect world, a user would (by default) be required to enter that password. In a "good enough" world, have the option to set the password.
If the threat model includes actively malicious people at the console, I'd rather see encrypted file systems than a grub password. (And that doesn't help if you don't realize that a malicious person may have had access and that you shouldn't trust the system any more.)
security@lists.fedoraproject.org
-
Adam Williamson -
Bill Nottingham -
Bruno Wolff III -
Eric Christensen -
Gene Czarcinski -
Jesse Keating -
Matthias Clasen -
Seth Vidal -
Toshio Kuratomi -
Vincent Danen