From awilliam at redhat.com Mon Nov 23 22:08:31 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 23 Nov 2009 14:08:31 -0800 Subject: Security testing: need for a security policy, and a security-critical package process Message-ID: <1259014111.9312.563.camel@adam.local.net> 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 From jkeating at redhat.com Mon Nov 23 22:33:32 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Nov 2009 14:33:32 -0800 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <1259014111.9312.563.camel@adam.local.net> References: <1259014111.9312.563.camel@adam.local.net> Message-ID: <1259015612.2405.45.camel@localhost.localdomain> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Nov 23 23:39:59 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Nov 2009 15:39:59 -0800 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <1259016915.1733.7.camel@planemask> References: <1259014111.9312.563.camel@adam.local.net> <1259016915.1733.7.camel@planemask> Message-ID: <1259019599.2405.49.camel@localhost.localdomain> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Mon Nov 23 22:55:15 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 23 Nov 2009 17:55:15 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <1259014111.9312.563.camel@adam.local.net> References: <1259014111.9312.563.camel@adam.local.net> Message-ID: <1259016915.1733.7.camel@planemask> 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. From skvidal at fedoraproject.org Mon Nov 23 23:31:12 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 23 Nov 2009 18:31:12 -0500 (EST) Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <1259016915.1733.7.camel@planemask> References: <1259014111.9312.563.camel@adam.local.net> <1259016915.1733.7.camel@planemask> Message-ID: 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 From mclasen at redhat.com Tue Nov 24 00:31:46 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 23 Nov 2009 19:31:46 -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> <1259016915.1733.7.camel@planemask> Message-ID: <1259022706.1733.9.camel@planemask> 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. From skvidal at fedoraproject.org Tue Nov 24 00:36:16 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 23 Nov 2009 19:36:16 -0500 (EST) Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <1259022706.1733.9.camel@planemask> References: <1259014111.9312.563.camel@adam.local.net> <1259016915.1733.7.camel@planemask> <1259022706.1733.9.camel@planemask> Message-ID: 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 From mclasen at redhat.com Tue Nov 24 00:38:55 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 23 Nov 2009 19:38:55 -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> <1259016915.1733.7.camel@planemask> <1259022706.1733.9.camel@planemask> Message-ID: <1259023135.1733.13.camel@planemask> 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. From skvidal at fedoraproject.org Tue Nov 24 00:54:11 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 23 Nov 2009 19:54:11 -0500 (EST) Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <1259023135.1733.13.camel@planemask> References: <1259014111.9312.563.camel@adam.local.net> <1259016915.1733.7.camel@planemask> <1259022706.1733.9.camel@planemask> <1259023135.1733.13.camel@planemask> Message-ID: 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 From awilliam at redhat.com Tue Nov 24 02:01:44 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 23 Nov 2009 18:01:44 -0800 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <1259015612.2405.45.camel@localhost.localdomain> References: <1259014111.9312.563.camel@adam.local.net> <1259015612.2405.45.camel@localhost.localdomain> Message-ID: <1259028104.9312.564.camel@adam.local.net> 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 From awilliam at redhat.com Tue Nov 24 02:10:59 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 23 Nov 2009 18:10:59 -0800 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <1259023135.1733.13.camel@planemask> References: <1259014111.9312.563.camel@adam.local.net> <1259016915.1733.7.camel@planemask> <1259022706.1733.9.camel@planemask> <1259023135.1733.13.camel@planemask> Message-ID: <1259028659.9312.568.camel@adam.local.net> 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 From vdanen at redhat.com Tue Nov 24 02:36:56 2009 From: vdanen at redhat.com (Vincent Danen) Date: Mon, 23 Nov 2009 19:36:56 -0700 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> <1259016915.1733.7.camel@planemask> <1259022706.1733.9.camel@planemask> <1259023135.1733.13.camel@planemask> Message-ID: <20091124023656.GO3660@redhat.com> * [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. -- Vincent Danen / Red Hat Security Response Team From eric at christensenplace.us Tue Nov 24 03:36:58 2009 From: eric at christensenplace.us (Eric Christensen) Date: Mon, 23 Nov 2009 22:36:58 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <1259028659.9312.568.camel@adam.local.net> References: <1259014111.9312.563.camel@adam.local.net> <1259016915.1733.7.camel@planemask> <1259022706.1733.9.camel@planemask> <1259023135.1733.13.camel@planemask> <1259028659.9312.568.camel@adam.local.net> Message-ID: <1259033818.5240.12.camel@localhost> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Tue Nov 24 16:19:06 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 24 Nov 2009 08:19:06 -0800 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <1259028659.9312.568.camel@adam.local.net> References: <1259014111.9312.563.camel@adam.local.net> <1259016915.1733.7.camel@planemask> <1259022706.1733.9.camel@planemask> <1259023135.1733.13.camel@planemask> <1259028659.9312.568.camel@adam.local.net> Message-ID: <20091124161906.GN3724@clingman.lan> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mattdm at mattdm.org Tue Nov 24 16:26:06 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 24 Nov 2009 11:26:06 -0500 Subject: PolicyKit and syslog Message-ID: <20091124162606.GA5293@jadzia.bu.edu> One of the important features of sudo is its ability to log elevated-access actions to syslog. Userhelper similarly logs actions, like so: "userhelper[26491]: running '/usr/share/system-config-users/system-config-users ' with root privileges on behalf of 'mattdm'". PolicyKit serves a similar function, but doesn't seem to log anything. In fact, the only use of syslog appears to be in polkit-agent-helper-1, which logs in two possible situations -- when called with the wrong number of arguments and when stdin is a tty. (Most other things it fprintfs to stderr.) I'm not bringing this up to complain -- I just want to make sure that I'm not missing something (which happens more often than it should; *sigh*). If I'm not missing something, is this something anyone is working on already or has existing plans for? -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs / Instructional & Research Computing Computing & Information Technology Harvard School of Engineering & Applied Sciences From mclasen at redhat.com Tue Nov 24 16:35:13 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 24 Nov 2009 11:35:13 -0500 Subject: PolicyKit and syslog In-Reply-To: <20091124162606.GA5293@jadzia.bu.edu> References: <20091124162606.GA5293@jadzia.bu.edu> Message-ID: <1259080513.1855.23.camel@planemask> On Tue, 2009-11-24 at 11:26 -0500, Matthew Miller wrote: > One of the important features of sudo is its ability to log elevated-access > actions to syslog. > > Userhelper similarly logs actions, like so: "userhelper[26491]: running > '/usr/share/system-config-users/system-config-users ' with root privileges > on behalf of 'mattdm'". > > PolicyKit serves a similar function, but doesn't seem to log anything. > > In fact, the only use of syslog appears to be in polkit-agent-helper-1, > which logs in two possible situations -- when called with the wrong number > of arguments and when stdin is a tty. (Most other things it fprintfs to > stderr.) > > I'm not bringing this up to complain -- I just want to make sure that I'm > not missing something (which happens more often than it should; *sigh*). If > I'm not missing something, is this something anyone is working on already or > has existing plans for? > PolicyKit itself is not running anything. It is just answering the question of a mechanism: 'is X allowed to do foo ?'. It would make more sense for the mechanisms that use PolicyKit to log privileged actions that they do or deny to do. From skvidal at fedoraproject.org Tue Nov 24 16:47:03 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 24 Nov 2009 11:47:03 -0500 (EST) Subject: PolicyKit and syslog In-Reply-To: <20091124162606.GA5293@jadzia.bu.edu> References: <20091124162606.GA5293@jadzia.bu.edu> Message-ID: On Tue, 24 Nov 2009, Matthew Miller wrote: > One of the important features of sudo is its ability to log elevated-access > actions to syslog. > > Userhelper similarly logs actions, like so: "userhelper[26491]: running > '/usr/share/system-config-users/system-config-users ' with root privileges > on behalf of 'mattdm'". > > PolicyKit serves a similar function, but doesn't seem to log anything. > > In fact, the only use of syslog appears to be in polkit-agent-helper-1, > which logs in two possible situations -- when called with the wrong number > of arguments and when stdin is a tty. (Most other things it fprintfs to > stderr.) > > I'm not bringing this up to complain -- I just want to make sure that I'm > not missing something (which happens more often than it should; *sigh*). If > I'm not missing something, is this something anyone is working on already or > has existing plans for? > I see nothing noting any changes to the policy state whatsoever. I'd recommend filing this as a bug. thanks, -sv From skvidal at fedoraproject.org Tue Nov 24 16:48:11 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 24 Nov 2009 11:48:11 -0500 (EST) Subject: PolicyKit and syslog In-Reply-To: <1259080513.1855.23.camel@planemask> References: <20091124162606.GA5293@jadzia.bu.edu> <1259080513.1855.23.camel@planemask> Message-ID: On Tue, 24 Nov 2009, Matthias Clasen wrote: > On Tue, 2009-11-24 at 11:26 -0500, Matthew Miller wrote: >> One of the important features of sudo is its ability to log elevated-access >> actions to syslog. >> >> Userhelper similarly logs actions, like so: "userhelper[26491]: running >> '/usr/share/system-config-users/system-config-users ' with root privileges >> on behalf of 'mattdm'". >> >> PolicyKit serves a similar function, but doesn't seem to log anything. >> >> In fact, the only use of syslog appears to be in polkit-agent-helper-1, >> which logs in two possible situations -- when called with the wrong number >> of arguments and when stdin is a tty. (Most other things it fprintfs to >> stderr.) >> >> I'm not bringing this up to complain -- I just want to make sure that I'm >> not missing something (which happens more often than it should; *sigh*). If >> I'm not missing something, is this something anyone is working on already or >> has existing plans for? >> > > PolicyKit itself is not running anything. It is just answering the > question of a mechanism: 'is X allowed to do foo ?'. It would make more > sense for the mechanisms that use PolicyKit to log privileged actions > that they do or deny to do. > when the policies are updated it is policy kit that has to be involved. polkitd is running, at least. It would make sense for polkitd to note a change to a policy. Maybe also to note any communications to polkitd of any kind. -sv From mclasen at redhat.com Tue Nov 24 16:55:25 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 24 Nov 2009 11:55:25 -0500 Subject: PolicyKit and syslog In-Reply-To: References: <20091124162606.GA5293@jadzia.bu.edu> <1259080513.1855.23.camel@planemask> Message-ID: <1259081725.1855.25.camel@planemask> On Tue, 2009-11-24 at 11:48 -0500, Seth Vidal wrote: > > > > when the policies are updated it is policy kit that has to be involved. > polkitd is running, at least. That might be ok to log, indeed. polkitd need not be running, though. It is activated as needed. > It would make sense for polkitd to note a change to a policy. Maybe also > to note any communications to polkitd of any kind. That I would consider spamming. But maybe at absurd log levels... From skvidal at fedoraproject.org Tue Nov 24 17:06:22 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 24 Nov 2009 12:06:22 -0500 (EST) Subject: PolicyKit and syslog In-Reply-To: <1259081725.1855.25.camel@planemask> References: <20091124162606.GA5293@jadzia.bu.edu> <1259080513.1855.23.camel@planemask> <1259081725.1855.25.camel@planemask> Message-ID: On Tue, 24 Nov 2009, Matthias Clasen wrote: > On Tue, 2009-11-24 at 11:48 -0500, Seth Vidal wrote: > >>> >> >> when the policies are updated it is policy kit that has to be involved. >> polkitd is running, at least. > > That might be ok to log, indeed. polkitd need not be running, though. It > is activated as needed. > >> It would make sense for polkitd to note a change to a policy. Maybe also >> to note any communications to polkitd of any kind. > > That I would consider spamming. But maybe at absurd log levels... Policy changes should be warning level notices b/c it notes a change in state. any/all communication should be at debug level notices. debugging is a lot easier when you can follow the whole process along. -sv From mattdm at mattdm.org Tue Nov 24 17:29:36 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 24 Nov 2009 12:29:36 -0500 Subject: PolicyKit and syslog In-Reply-To: <1259080513.1855.23.camel@planemask> References: <20091124162606.GA5293@jadzia.bu.edu> <1259080513.1855.23.camel@planemask> Message-ID: <20091124172936.GA10504@jadzia.bu.edu> On Tue, Nov 24, 2009 at 11:35:13AM -0500, Matthias Clasen wrote: > PolicyKit itself is not running anything. It is just answering the > question of a mechanism: 'is X allowed to do foo ?'. It would make more > sense for the mechanisms that use PolicyKit to log privileged actions > that they do or deny to do. That makes sense. However, I can see strengths in both approaches. A good analogy is PAM, particularly the "auth" section, which does basically the same thing? as PolicyKit. There, you get logs both from the application itself and from PAM directly. There are four particular strengths I see in logging at the PolicyKit level. 1) Existing applications don't need to be changed, and new applications don't need to be counted on to do the right thing. Appropriate logging just starts happening. 2) Log levels and debugging are easier to admin because there's a central configuration (and PolicyKit already has config files). If I want to turn on more authentication 3) Log messages are automatically consistent between programs, making analysis and monitoring much easier. 4) PolicyKit is in a position to log more about the decisions it makes than is (or should be) exposed to the client application. This can be particularly useful for debugging but may also be useful for auditing. (If a user was allowed access for a certain reason, and that reason turns out to be something they shouldn't have access to but do, we can know to investigate.) Also, since this is a security/auditing issue, I thing it's never wrong to error on the side of more logging. I absolutely agree that client applications should also log their elevated-privilege actions. ---- 1. In fact, a PAM-backed authority for PolicyKit might be interesting and useful -- but there's a tangent. -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs / Instructional & Research Computing Computing & Information Technology Harvard School of Engineering & Applied Sciences From mattdm at mattdm.org Tue Nov 24 17:31:06 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 24 Nov 2009 12:31:06 -0500 Subject: PolicyKit and syslog In-Reply-To: References: <20091124162606.GA5293@jadzia.bu.edu> Message-ID: <20091124173106.GB10504@jadzia.bu.edu> On Tue, Nov 24, 2009 at 11:47:03AM -0500, Seth Vidal wrote: > I'd recommend filing this as a bug. I definitely will -- I just want to get some feedback first. -- Matthew Miller mattdm at mattdm.org From mclasen at redhat.com Tue Nov 24 17:44:00 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 24 Nov 2009 12:44:00 -0500 Subject: PolicyKit and syslog In-Reply-To: <20091124172936.GA10504@jadzia.bu.edu> References: <20091124162606.GA5293@jadzia.bu.edu> <1259080513.1855.23.camel@planemask> <20091124172936.GA10504@jadzia.bu.edu> Message-ID: <1259084640.2512.5.camel@planemask> On Tue, 2009-11-24 at 12:29 -0500, Matthew Miller wrote: > 1. In fact, a PAM-backed authority for PolicyKit might be interesting and > useful -- but there's a tangent. What do you think PolicyKit is using for authentication ? See http://cgit.freedesktop.org/PolicyKit/tree/src/polkitagent/polkitagenthelper.c From mattdm at mattdm.org Tue Nov 24 18:18:21 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 24 Nov 2009 13:18:21 -0500 Subject: tangent: PolicyKit and PAM In-Reply-To: <1259084640.2512.5.camel@planemask> References: <20091124162606.GA5293@jadzia.bu.edu> <1259080513.1855.23.camel@planemask> <20091124172936.GA10504@jadzia.bu.edu> <1259084640.2512.5.camel@planemask> Message-ID: <20091124181821.GA14741@jadzia.bu.edu> On Tue, Nov 24, 2009 at 12:44:00PM -0500, Matthias Clasen wrote: > > 1. In fact, a PAM-backed authority for PolicyKit might be interesting and > > useful -- but there's a tangent. > What do you think PolicyKit is using for authentication ? > See > http://cgit.freedesktop.org/PolicyKit/tree/src/polkitagent/polkitagenthelper.c It uses it for authentication *and* for authorization, but it uses one service name (polkit-1) for everything (which is in turn configured by default to just defer to the standard system-auth service definition). This arrangement isn't particularly useful for a flexible authorization policy. You can use it for the big-hammer "user-is-locked out" stuff, but not for things like "local users can install packages without a password, only during business hours", which PAM is perfectly expressive enough to do (with existing modules, even). I don't think, offhand, that it could be quite as flexible as the Local Authority currently in PolicyKit or via some fancy LDAP Authority, but I don't think it necessarily would need to be. The main advantage would be that instead of having yet another way (and again, I want to emphasize that I think PolicyKit is good work) to implement authorization policy, one could use PolicyKit with a well-understood mechanism that's been in production use since the 90s. Like I said, this is a tangent, and I'm certainly not expecting anyone to work on this. But it'd be cool if they did. -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs / Instructional & Research Computing Computing & Information Technology Harvard School of Engineering & Applied Sciences From notting at redhat.com Tue Nov 24 18:28:24 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 24 Nov 2009 13:28:24 -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> <1259016915.1733.7.camel@planemask> <1259022706.1733.9.camel@planemask> <1259023135.1733.13.camel@planemask> Message-ID: <20091124182823.GG12433@nostromo.devel.redhat.com> > >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 From mclasen at redhat.com Tue Nov 24 18:27:40 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 24 Nov 2009 13:27:40 -0500 Subject: tangent: PolicyKit and PAM In-Reply-To: <20091124181821.GA14741@jadzia.bu.edu> References: <20091124162606.GA5293@jadzia.bu.edu> <1259080513.1855.23.camel@planemask> <20091124172936.GA10504@jadzia.bu.edu> <1259084640.2512.5.camel@planemask> <20091124181821.GA14741@jadzia.bu.edu> Message-ID: <1259087260.2512.10.camel@planemask> On Tue, 2009-11-24 at 13:18 -0500, Matthew Miller wrote: > Like I said, this is a tangent, and I'm certainly not expecting anyone to > work on this. But it'd be cool if they did. Just as everybody else is struggling to get away from pam's awful apis...I don't think this would be a step forward; but sure, it might be doable. From mattdm at mattdm.org Tue Nov 24 18:43:25 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 24 Nov 2009 13:43:25 -0500 Subject: tangent: PolicyKit and PAM In-Reply-To: <1259087260.2512.10.camel@planemask> References: <20091124162606.GA5293@jadzia.bu.edu> <1259080513.1855.23.camel@planemask> <20091124172936.GA10504@jadzia.bu.edu> <1259084640.2512.5.camel@planemask> <20091124181821.GA14741@jadzia.bu.edu> <1259087260.2512.10.camel@planemask> Message-ID: <20091124184325.GB14741@jadzia.bu.edu> On Tue, Nov 24, 2009 at 01:27:40PM -0500, Matthias Clasen wrote: > > Like I said, this is a tangent, and I'm certainly not expecting anyone to > > work on this. But it'd be cool if they did. > Just as everybody else is struggling to get away from pam's awful > apis...I don't think this would be a step forward; but sure, it might be > doable. The awful API is actually an argument _for_ doing such a thing: it gets encapsulated away in only one place that needs to be maintained, and everyone can just write to PolicyKit. Annd speaking of tangents and horrible interfaces, I should add that one thing I'm very genuinely happy to learn in all of this is that the pkla config files are key=value rather than the old PolicyKit.conf xml file. So much nicer for humans to work with! -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs / Instructional & Research Computing Computing & Information Technology Harvard School of Engineering & Applied Sciences From awilliam at redhat.com Tue Nov 24 18:44:34 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 24 Nov 2009 10:44:34 -0800 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <20091124182823.GG12433@nostromo.devel.redhat.com> References: <1259014111.9312.563.camel@adam.local.net> <1259016915.1733.7.camel@planemask> <1259022706.1733.9.camel@planemask> <1259023135.1733.13.camel@planemask> <20091124182823.GG12433@nostromo.devel.redhat.com> Message-ID: <1259088274.9312.588.camel@adam.local.net> 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 From skvidal at fedoraproject.org Tue Nov 24 18:44:16 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 24 Nov 2009 13:44:16 -0500 (EST) Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <20091124182823.GG12433@nostromo.devel.redhat.com> References: <1259014111.9312.563.camel@adam.local.net> <1259016915.1733.7.camel@planemask> <1259022706.1733.9.camel@planemask> <1259023135.1733.13.camel@planemask> <20091124182823.GG12433@nostromo.devel.redhat.com> Message-ID: 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 From skvidal at fedoraproject.org Tue Nov 24 18:53:51 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 24 Nov 2009 13:53:51 -0500 (EST) Subject: tangent: PolicyKit and PAM In-Reply-To: <20091124184325.GB14741@jadzia.bu.edu> References: <20091124162606.GA5293@jadzia.bu.edu> <1259080513.1855.23.camel@planemask> <20091124172936.GA10504@jadzia.bu.edu> <1259084640.2512.5.camel@planemask> <20091124181821.GA14741@jadzia.bu.edu> <1259087260.2512.10.camel@planemask> <20091124184325.GB14741@jadzia.bu.edu> Message-ID: On Tue, 24 Nov 2009, Matthew Miller wrote: > On Tue, Nov 24, 2009 at 01:27:40PM -0500, Matthias Clasen wrote: >>> Like I said, this is a tangent, and I'm certainly not expecting anyone to >>> work on this. But it'd be cool if they did. >> Just as everybody else is struggling to get away from pam's awful >> apis...I don't think this would be a step forward; but sure, it might be >> doable. > > The awful API is actually an argument _for_ doing such a thing: it gets > encapsulated away in only one place that needs to be maintained, and > everyone can just write to PolicyKit. > And in general having the logging of security-elevation events be in the lowest common denominator piece of code or interface keeps important information from getting lost due to insufficient logging in a calling app. -sv From awilliam at redhat.com Tue Nov 24 18:54:49 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 24 Nov 2009 10:54:49 -0800 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <1259088274.9312.588.camel@adam.local.net> References: <1259014111.9312.563.camel@adam.local.net> <1259016915.1733.7.camel@planemask> <1259022706.1733.9.camel@planemask> <1259023135.1733.13.camel@planemask> <20091124182823.GG12433@nostromo.devel.redhat.com> <1259088274.9312.588.camel@adam.local.net> Message-ID: <1259088889.9312.590.camel@adam.local.net> 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 From mattdm at mattdm.org Tue Nov 24 19:38:42 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 24 Nov 2009 14:38:42 -0500 Subject: PolicyKit and syslog -- now bug #541040 In-Reply-To: References: <20091124162606.GA5293@jadzia.bu.edu> Message-ID: <20091124193842.GA22482@jadzia.bu.edu> On Tue, Nov 24, 2009 at 11:47:03AM -0500, Seth Vidal wrote: > I'd recommend filing this as a bug. Bug 541040 - Enable logging in PolicyKit (for policy changes and for authorizations.) https://bugzilla.redhat.com/show_bug.cgi?id=541040 -- Matthew Miller mattdm at mattdm.org From mattdm at mattdm.org Wed Nov 25 02:31:26 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 24 Nov 2009 21:31:26 -0500 Subject: PolicyKit and syslog -- now bug #541040 In-Reply-To: <20091124193842.GA22482@jadzia.bu.edu> References: <20091124162606.GA5293@jadzia.bu.edu> <20091124193842.GA22482@jadzia.bu.edu> Message-ID: <20091125023126.GA22320@jadzia.bu.edu> On Tue, Nov 24, 2009 at 02:38:42PM -0500, Matthew Miller wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=541040 So one thing that occurs to me as soon as I start poking at the code -- it's relatively easy to have it emit a log message when a policy file is changed, but this is largely useless because there's no way to verify the policy state _at startup_. So I think it's probably better to leave that aspect to more traditional tools for monitoring file changes. -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs / Instructional & Research Computing Computing & Information Technology Harvard School of Engineering & Applied Sciences From gene at czarc.net Mon Nov 30 20:09:50 2009 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 30 Nov 2009 15:09:50 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <1259014111.9312.563.camel@adam.local.net> References: <1259014111.9312.563.camel@adam.local.net> Message-ID: <200911301509.50553.gene@czarc.net> 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 From eric at christensenplace.us Mon Nov 30 20:17:34 2009 From: eric at christensenplace.us (Eric Christensen) Date: Mon, 30 Nov 2009 15:17:34 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <200911301509.50553.gene@czarc.net> References: <1259014111.9312.563.camel@adam.local.net> <200911301509.50553.gene@czarc.net> Message-ID: On Mon, Nov 30, 2009 at 15:09, Gene Czarcinski 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Mon Nov 30 20:43:26 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 30 Nov 2009 15:43:26 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <200911301509.50553.gene@czarc.net> References: <1259014111.9312.563.camel@adam.local.net> <200911301509.50553.gene@czarc.net> Message-ID: <20091130204326.GB17480@nostromo.devel.redhat.com> Gene Czarcinski (gene at 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 From gene at czarc.net Mon Nov 30 21:39:05 2009 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 30 Nov 2009 16:39:05 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <20091130204326.GB17480@nostromo.devel.redhat.com> References: <1259014111.9312.563.camel@adam.local.net> <200911301509.50553.gene@czarc.net> <20091130204326.GB17480@nostromo.devel.redhat.com> Message-ID: <200911301639.05915.gene@czarc.net> On Monday 30 November 2009 15:43:26 Bill Nottingham wrote: > Gene Czarcinski (gene at 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 From awilliam at redhat.com Mon Nov 30 23:16:50 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 30 Nov 2009 15:16:50 -0800 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> <200911301509.50553.gene@czarc.net> Message-ID: <1259623010.9312.778.camel@adam.local.net> 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net