4:08 p.m.
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...
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
4:33 p.m.
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
8:01 p.m.
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
4:55 p.m.
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.
5:31 p.m.
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
6:31 p.m.
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.
6:36 p.m.
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
6:38 p.m.
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.
6:54 p.m.
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
12:28 p.m.
>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
12:44 p.m.
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
12:44 p.m.
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
12:54 p.m.
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
8:10 p.m.
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
8:18 p.m.
New subject: Security testing: need for a security policy, and a security-critical package process
On Mon, Nov 23, 2009 at 9:10 PM, Adam Williamson <awilliam(a)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.
12:29 p.m.
Gregory Maxwell (gmaxwell(a)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
1:50 p.m.
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 <mattdm(a)mattdm.org>
Senior Systems Architect
Cyberinfrastructure Labs / Instructional & Research Computing
Computing & Information Technology
Harvard School of Engineering & Applied Sciences
2:07 p.m.
Hi,
Gregory Maxwell (gmaxwell(a)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.)
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.)
- Chris.
--
Chris Ball <cjb(a)laptop.org>
One Laptop Per Child
2:34 p.m.
Chris Ball (cjb(a)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
2:40 p.m.
On Tue, 2009-11-24 at 15:34 -0500, Bill Nottingham wrote:
Chris Ball (cjb(a)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
2:44 p.m.
Adam Williamson (awilliam(a)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
2:47 p.m.
On Tue, 2009-11-24 at 15:44 -0500, Bill Nottingham wrote:
Adam Williamson (awilliam(a)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.
I dunno, but as an outsider for most of those 4 years I never remotely
considered Sugar or XO or SoaS to be 'Fedora projects' and wouldn't have
tied any problems with them into the image of 'the Fedora project', for
what that's worth.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:52 p.m.
Hi,
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.
Right, but "based on Fedora" is fine: it correctly conveys the
impression that we took a pristine and sane Fedora and then messed
around with it to our heart's content. :)
I don't think anyone's left with the impression that OLPC's security
choices are a direct duplicate of Fedora's, which *is* a reasonable
impression to have if you download a Fedora spin that's advertised, as
most spins are, as "the core of Fedora plus some app you really like".
- Chris.
--
Chris Ball <cjb(a)laptop.org>
One Laptop Per Child
9:36 p.m.
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
10:19 a.m.
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
5:39 p.m.
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
8:09 p.m.
New subject: Security testing: need for a security policy, and a security-critical package process
On Mon, Nov 23, 2009 at 6:39 PM, Jesse Keating <jkeating(a)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.
5:54 p.m.
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
5:56 p.m.
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
6:16 p.m.
Once upon a time, Adam Williamson <awilliam(a)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 <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:05 p.m.
On Mon, 2009-11-23 at 18:16 -0600, Chris Adams wrote:
Once upon a time, Adam Williamson <awilliam(a)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
2:09 p.m.
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
2:17 p.m.
New subject: Security testing: need for a security policy, and a security-critical package process
On Mon, Nov 30, 2009 at 15:09, Gene Czarcinski <gene(a)czarc.net> wrote:
Although I have read all of the messages on this thread as of the
date/time
of
this message, I am replying to this first message with all of my comments.
My background: I am currently retired but a few years ago I was still being
paid the big bucks for working on computer security and security assessment
of
systems in US classified environments.
On the whole, I believe that Adam has outlined a good approach to the
problem
of doing QA on security for Fedora!
General comment: I have read messages which claim that the approach is
wrong
and that we need to look at things that a user can do rather than what a
user
cannot do. I disagree. While the right approach for design/development is
to
assume that a user can do nothing except what they are specifically
authorized
to do, for security QA this needs to be turned around and the testing needs
to
demonstrate what a user cannot do.
On Monday 23 November 2009 17:08:31 Adam Williamson wrote:
> We can't do any meaningful security testing without knowing exactly what
> we should be testing for, in which packages. I believe Seth Vidal's
> upcoming proposal for covering 'major changes' may touch on this, but I
> doubt they'll cover exactly the same ground.
>
> So, if we are to have meaningful security testing in future releases -
> which QA believes would be a good thing - we need the project to define
> a security policy. We believe there's a genuine need for this anyway, as
> the introduction and widespread adoption of PolicyKit will likely lead
> to much more complex and significant potential changes in security
> posture than any previous change.
>
> It's not QA's role to define exactly what the security policy should
> look like or what it should cover, but from the point of view of
> testing, what we really need are concrete requirements. The policy does
> not have to be immediately comprehensive - try and cover every possible
> security-related issue - to be valuable. Something as simple as spot's
> proposed list of things an unprivileged user must not be able to do -
> http://spot.livejournal.com/312216.html - would serve a valuable purpose
> here.
+1
A written description of the security policy is a must! Without it being
written down in simple english (with translations as appropriate), there
will
be far too much subjective interpretation of what the policy is. I believe
spot's list is a good starting point for F13.
However, the policy should consider how Fedora should work with respect to
security and not how it does work as currently implemented. For example,
you
cannot currently login as root from the gui (gdm) interface but you can
login
as root from a virtual terminal ... is this the way the system should work?
Keep it simple (KISS) for the initial attempt. It will grow more
complicated
all by itself as time passes.
BTW, the security policy should assume that a grub password is in use so
that
a user cannot do something like disabling selinux by editing the kernel
command line. This should be tested by the security QA.
>
> The second thing QA would require, aside from a policy with concrete and
> testable requirements, is a list of security-sensitive components to
> test. Obviously we couldn't test every package in the entire
> distribution for compliance with even such a simple list as spot's, and
> it would be a waste of time to try.
+1
You definitely need to define a "reference implementation" that will be
tested.
Security assurance testing is done on "as-built" systems ... not "as
designed"! It may be possible but is not practical to test everything. [or
will take so long that the release will no longer be supported]
Furthermore, I believe you should initially focus on a small subset of what
is
in Fedora (perhaps gnome only) and with a selected set of services
(servers).
At this point in time, considering all of the various windows
implementations
(gnome, kde, openbox, xfce, etc.) will result in a lot of motion but little
of
it in a forward direction. KISS!!!
...........
Given a written security policy for Fedora and a written description of the
"reference implementation" that will be tested, these need to be vetted and
"tuned" from comments.
After a reasonable amount of time, these documents/specifications should be
approved by the Fedora Executive Committee (or whatever). Any variation or
change, should require additional approval. There should be some
independent
oversight of the security QA process to minimize subjective
(re)interpretation.
This will NOT make everyone happy. Sorry, but there is only so much
resources
and you really do not want this to be a black hole which consumes
everything
else.
Start small, grow, and learn. Two years from now, the security policy, the
reference installation/configurations, and the QA process for securtiy will
likely be very different.
Gene
Gene,
(Ahh... someone with a similar background...)
So the biggest question, to me, is to what standard do we start? There are
plenty to choose from from DISA to NIST. I, personally, find the NSA's
"Guide to the Secure Configuration of Red Hat Enterprise Linux 5" very good
and might be a good place to start. I'm not saying that we do everything
that is in the guide but maybe take the guide and strike things out that
don't make sense and add stuff to it that does make sense.
Thoughts?
--Eric
5:16 p.m.
New subject: Security testing: need for a security policy, and a security-critical package process
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
11:47 a.m.
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
12:04 p.m.
New subject: Security testing: need for a security policy, and a security-critical package process
On Tue, Dec 1, 2009 at 12:47, Gene Czarcinski <gene(a)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
2:10 p.m.
On Tuesday 01 December 2009 13:04:02 Eric Christensen wrote:
On Tue, Dec 1, 2009 at 12:47, Gene Czarcinski <gene(a)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
12:56 p.m.
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
1:56 p.m.
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
2:43 p.m.
Gene Czarcinski (gene(a)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
5258
days inactive
5266
days old
40 comments
13 participants
participants (13)
-
"Jóhann B. Guðmundsson" -
Adam Williamson -
Bill Nottingham -
Chris Adams -
Chris Ball -
Eric Christensen -
Gene Czarcinski -
Gregory Maxwell -
Jesse Keating -
Matthew Miller -
Matthias Clasen -
Seth Vidal -
Toshio Kuratomi