On Mon, 23 Nov 2009, Matthias Clasen wrote:
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote:
It's not QA's role to define exactly what the security policy should
look like or what it should cover, but from the point of view of
testing, what we really need are concrete requirements. The policy does
not have to be immediately comprehensive - try and cover every possible
security-related issue - to be valuable. Something as simple as spot's
proposed list of things an unprivileged user must not be able to do -
http://spot.livejournal.com/312216.html - would serve a valuable purpose
here.
I don't think spots list is too useful, unfortunately; discussing an
abstract 'unprivileged user' without defining some roles and use cases
doesn't make much sense to me. There is probably a difference between a
guest account and a regular (non-admin) user in what I want them to be
able to do; 'unprivileged user' does not allow that distinction. And
there is certainly a difference between what a regular user is expected
to be allowed on a family computer vs a university computer lab.
And this is why spot's list is useful.
A family computer and a university computer lab have a lot in common but
where they diverge we should start with err toward MORE restrictive and
allow configuration by the local admin/owner to LESS restrictive.
Otherwise we open ourselves up to a less-secure-by-default posture in an
average install.
We've been in that position in the past and it is not a favorable place to
be.
-sv
--
Fedora-security-list mailing list
Fedora-security-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-security-list
