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