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