Re: Security testing: need for a security policy, and a security-critical package process
On Monday 30 November 2009 22:40:07 Hal Murray wrote: g...@czarc.net said: ... A written description of the security policy is a must! ... Is the idea of a single one-size-fits-all security policy reasonable? I think Fedora has a broad range of users. No. Initially, I recommend one security policy and one reference implementation to test against. Each variation needs its own security policy and reference implementation definition. Later ones are easier to create because they can use the early ones as guidance. So, why go through all of this paperwork and bureaucratic bullshit? Well, those of us who have done this before believe that it is necessary. I do not like the bureaucratic BS any more than anyone else but, if you do not do it, then you are not quite sure what you have when you say that something meets security requirements. Gene -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, Nov 30, 2009 at 22:40, Hal Murray hmur...@megapathdsl.net wrote: g...@czarc.net said: ... A written description of the security policy is a must! ... Is the idea of a single one-size-fits-all security policy reasonable? I think Fedora has a broad range of users. Probably not but there are some basics that should be implemented for everyone. Security is a tradeoff. If you make it impossible for the bad guys to get in, the good guys probably can't get any work done. How secure do you need to be? How much are you willing to pay for it? How much are you willing to pay to clean up the aftermath? I'd much rather have an overview document that explains the likely attacks and potential solutions, and their costs and benefits. Additionally, I think it's much easier to follow a policy if I understand the reasonaing behind it. The Fedora Security Guide (found at docs.fedoraproject.org and in a friendly repo near you) started out that way and has blossomed into that and a whole lot more. As always suggestions and patches are welcome. I think sample policy documents with descriptions of their target audience and checklists for how to implement them would be helpful. +1 --Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Tue, Dec 1, 2009 at 12:47, Gene Czarcinski g...@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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Tuesday 01 December 2009 13:04:02 Eric Christensen wrote: On Tue, Dec 1, 2009 at 12:47, Gene Czarcinski g...@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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, Nov 30, 2009 at 15:09, Gene Czarcinski g...@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,
Re: Security testing: need for a security policy, and a security-critical package process
Gene Czarcinski (g...@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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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 pgpa3sZCYOABb.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
Gregory Maxwell (gmaxw...@gmail.com) said: If some some spin decided to make every user run as root, ship with no firewalling, have password-less accounts, or have insecure services enabled by default, etc. You mean Sugar as configured on the XO? (It has passwordless user, who can su without a password.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Tue, Nov 24, 2009 at 01:29:11PM -0500, Bill Nottingham wrote: You mean Sugar as configured on the XO? (It has passwordless user, who can su without a password.) Annnd if you set a root password, stuff breaks. -- Matthew Miller mat...@mattdm.org Senior Systems Architect Cyberinfrastructure Labs / Instructional Research Computing Computing Information Technology Harvard School of Engineering Applied Sciences -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
Chris Ball (c...@laptop.org) said: If some some spin decided to make every user run as root, ship with no firewalling, have password-less accounts, or have insecure services enabled by default, etc. You mean Sugar as configured on the XO? (It has passwordless user, who can su without a password.) It's true, but note that the XO software is technically a Remix rather than a Spin, so there aren't any technical requirements on it to satisfy the use of the Fedora mark. (I think I'd agree with Greg's point regarding official Fedora spins.) But if it was such a concern with respect to the Fedora brand and image, I would think the same argument would apply, even if it was just branded as a 'Fedora remix'. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Tue, 2009-11-24 at 15:34 -0500, Bill Nottingham wrote: Chris Ball (c...@laptop.org) said: If some some spin decided to make every user run as root, ship with no firewalling, have password-less accounts, or have insecure services enabled by default, etc. You mean Sugar as configured on the XO? (It has passwordless user, who can su without a password.) It's true, but note that the XO software is technically a Remix rather than a Spin, so there aren't any technical requirements on it to satisfy the use of the Fedora mark. (I think I'd agree with Greg's point regarding official Fedora spins.) But if it was such a concern with respect to the Fedora brand and image, I would think the same argument would apply, even if it was just branded as a 'Fedora remix'. SoaS is not Fedora-branded in any way, AFAIK. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
Adam Williamson (awill...@redhat.com) said: It's true, but note that the XO software is technically a Remix rather than a Spin, so there aren't any technical requirements on it to satisfy the use of the Fedora mark. (I think I'd agree with Greg's point regarding official Fedora spins.) But if it was such a concern with respect to the Fedora brand and image, I would think the same argument would apply, even if it was just branded as a 'Fedora remix'. SoaS is not Fedora-branded in any way, AFAIK. Yes, but how often have we touted XO, Sugar, et. al. as being 'based on Fedora' over the past 4 years? Heck, you could argue it's gotten more press than some of our official spins. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Security testing: need for a security policy, and a security-critical package process
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.2009-11-23-16.00.log.html 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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'. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, Nov 23, 2009 at 05:55:15PM -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. This is debatable. I certainly don't want a regular user at my family computer to be able to do anything they couldn't also do at a university computer. I don't want to worry about my ISP cutting off my internet access because one of my family members have enough permissions to get a trojan or virus installed on the system, for instance. The option to give other family members that much leeway as part of making things convenient for them to do other things can be a nice thing, but turning it on by default, even when it's possibly the most convenient approach, should be approached cautiously. Linux has several foundational features like being multiuser, designed with a security model that mitigates risk, and integrated into the network. When we touch these areas, we need to make sure that we're not compromising the foundations at the same time. -Toshio pgpGXp6oJV7Fc.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On 11/23/2009 10:55 PM, 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. I do believe we need to start securing from the (@)base level then gradually build service/users roles on top of that which will fit the intended spins service/audience. This means we would change the current default partition layout to a more secure seperated partition one. Disable dhcp. Disable ipv6. no running service etc.. Give us a solid secure base to work on then each spin or groups of spins that have the same target audience would build on top of that base and adjust and adapt according to it's intended audience and document why and how their security modules is different from the base one. Good example is that all the *DE could reach a consciousness on how the desktop home, desktop laptop/notebook and workstation security models should be and how they differentiate from the base security model and each other based on their function and roles. Same goes for server spins. When we have reach consciousness about what the base secure model should be, QA can create test cases ( or automate ) that fit that then gradually extend test cases to meet each defined security model desktop vs workstation vs server etc.. JBG -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
Once upon a time, Adam Williamson awill...@redhat.com said: 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. IMHO that's a backwards way of approaching security. You will never be able to define everything somebody should _not_ be able to do. You should always take the approach of defining what somebody _should_ be able to do. 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. During the recent discussion, somebody mentioned there are also ways to trigger events through dbus (I haven't looked down that path myself so I'm not sure of the details). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 2009-11-23 at 19:54 -0500, Seth Vidal wrote: We should not be forcing the choices for the desktop spin on everyone who installs a pkg in the distribution. Sure, I agree. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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 :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 2009-11-23 at 18:16 -0600, Chris Adams wrote: Once upon a time, Adam Williamson awill...@redhat.com said: 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. IMHO that's a backwards way of approaching security. You will never be able to define everything somebody should _not_ be able to do. You should always take the approach of defining what somebody _should_ be able to do. But think from a QA perspective. However the policy is phrased, we have to test the negatives. If we just tested that all the 'could' things on the list were OK, we would happily approve a release that gave everyone root privileges. After all, everyone would be able to do all the things they were supposed to do. it'd be a 100% pass. =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, Nov 23, 2009 at 6:39 PM, Jesse Keating jkeat...@redhat.com wrote: 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'. I tend to think of guest as equal to kiosk i.e. the user is expected to be toxic waste incarnate, with no accountability... and that it is acceptable to substantially limit a guest in a way which wouldn't be so acceptable for a regular user. For example, the account could be locked down with MLS so that regardless of how other users have (mis-)configured their home directory permissions guest can't touch it (or other user's files in /tmp), or strict ulimits on guests so they can't OOM the system or forkbomb it. Users that have named accounts can usually be presumed to have some accountability: they may be clueless but if they do something malicious you know who they are. They're also less likely to enjoy bizarre limitations on their abilities. I think this generally maps well to the capabilities of a regular user account on a classic multi-user unix system. I suppose you could go on to define a kind of power-user role which has, effectively, all the 'safe' parts of root... the idea being that the user probably has root on the system in any case, so giving the safe bits (mostly various system level settings like adjusting the time, user-application add/remove, system updates, etc) makes things easier and eliminates transitions to the more dangerous admin account. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, Nov 23, 2009 at 9:10 PM, Adam Williamson awill...@redhat.com wrote: 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 [snip] Different spins having different security makes sense, especially if the differences are well documented. Hopefully the differences are an invitation to do bone-headed things: If some some spin decided to make every user run as root, ship with no firewalling, have password-less accounts, or have insecure services enabled by default, etc. it would risk tarnishing the Fedora image and result in Fedora being banned from networks even if it really was just the insecure-spin. I'm sure that everyone can be trusted not to do these things, but it may be worth stating explicitly that security should be a goal for all spins— only the details of the trade-offs should differ. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
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 signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
