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

["Jóhann B. Guðmundsson"]

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

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

JBG