From bruno at wolff.to Tue Dec 1 01:48:08 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 30 Nov 2009 19:48:08 -0600 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <200911301639.05915.gene@czarc.net> References: <1259014111.9312.563.camel@adam.local.net> <200911301509.50553.gene@czarc.net> <20091130204326.GB17480@nostromo.devel.redhat.com> <200911301639.05915.gene@czarc.net> Message-ID: <20091201014808.GA9829@wolff.to> On Mon, Nov 30, 2009 at 16:39:05 -0500, Gene Czarcinski 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.) From hmurray at megapathdsl.net Tue Dec 1 03:40:07 2009 From: hmurray at megapathdsl.net (Hal Murray) Date: Mon, 30 Nov 2009 19:40:07 -0800 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: Message from Gene Czarcinski of "Mon, 30 Nov 2009 15:09:50 EST." <200911301509.50553.gene@czarc.net> Message-ID: <20091201034008.C1FEABCFC@ip-64-139-1-69.sjc.megapath.net> gene at 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. 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? 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. I think sample policy documents with descriptions of their target audience and checklists for how to implement them would be helpful. -- These are my opinions, not necessarily my employer's. I hate spam. From gene at czarc.net Tue Dec 1 17:38:25 2009 From: gene at czarc.net (Gene Czarcinski) Date: Tue, 1 Dec 2009 12:38:25 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <20091201034008.C1FEABCFC@ip-64-139-1-69.sjc.megapath.net> References: <20091201034008.C1FEABCFC@ip-64-139-1-69.sjc.megapath.net> Message-ID: <200912011238.25166.gene@czarc.net> On Monday 30 November 2009 22:40:07 Hal Murray wrote: > gene at 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 From gene at czarc.net Tue Dec 1 17:47:26 2009 From: gene at czarc.net (Gene Czarcinski) Date: Tue, 1 Dec 2009 12:47:26 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <1259623010.9312.778.camel@adam.local.net> References: <1259014111.9312.563.camel@adam.local.net> <1259623010.9312.778.camel@adam.local.net> Message-ID: <200912011247.26758.gene@czarc.net> 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 From eric at christensenplace.us Tue Dec 1 17:47:23 2009 From: eric at christensenplace.us (Eric Christensen) Date: Tue, 1 Dec 2009 12:47:23 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <20091201034008.C1FEABCFC@ip-64-139-1-69.sjc.megapath.net> References: <200911301509.50553.gene@czarc.net> <20091201034008.C1FEABCFC@ip-64-139-1-69.sjc.megapath.net> Message-ID: On Mon, Nov 30, 2009 at 22:40, Hal Murray wrote: > > gene at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at christensenplace.us Tue Dec 1 18:04:02 2009 From: eric at christensenplace.us (Eric Christensen) Date: Tue, 1 Dec 2009 13:04:02 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <200912011247.26758.gene@czarc.net> References: <1259014111.9312.563.camel@adam.local.net> <1259623010.9312.778.camel@adam.local.net> <200912011247.26758.gene@czarc.net> Message-ID: On Tue, Dec 1, 2009 at 12:47, Gene Czarcinski 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From awilliam at redhat.com Tue Dec 1 18:56:51 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 01 Dec 2009 10:56:51 -0800 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <200912011247.26758.gene@czarc.net> References: <1259014111.9312.563.camel@adam.local.net> <1259623010.9312.778.camel@adam.local.net> <200912011247.26758.gene@czarc.net> Message-ID: <1259693811.487.11.camel@adam.local.net> 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 From gene at czarc.net Tue Dec 1 19:56:20 2009 From: gene at czarc.net (Gene Czarcinski) Date: Tue, 1 Dec 2009 14:56:20 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <1259693811.487.11.camel@adam.local.net> References: <1259014111.9312.563.camel@adam.local.net> <200912011247.26758.gene@czarc.net> <1259693811.487.11.camel@adam.local.net> Message-ID: <200912011456.20917.gene@czarc.net> 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 From gene at czarc.net Tue Dec 1 20:10:29 2009 From: gene at czarc.net (Gene Czarcinski) Date: Tue, 1 Dec 2009 15:10:29 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: References: <1259014111.9312.563.camel@adam.local.net> <200912011247.26758.gene@czarc.net> Message-ID: <200912011510.29511.gene@czarc.net> On Tuesday 01 December 2009 13:04:02 Eric Christensen wrote: > On Tue, Dec 1, 2009 at 12:47, Gene Czarcinski 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