[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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
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..


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]