Security testing: need for a security policy, and a security-critical package process

[Seth Vidal]

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