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

[Toshio Kuratomi]

On Mon, Nov 23, 2009 at 05:55:15PM -0500, 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.
> 
This is debatable.  I certainly don't want a regular user at my family
computer to be able to do anything they couldn't also do at a university
computer.  I don't want to worry about my ISP cutting off my internet access
because one of my family members have enough permissions to get a trojan or
virus installed on the system, for instance.

The option to give other family members that much leeway as part of making
things convenient for them to do other things can be a nice thing, but
turning it on by default, even when it's possibly the most convenient
approach, should be approached cautiously.  Linux has several foundational
features like being multiuser, designed with a security model that mitigates
risk, and integrated into the network.  When we touch these areas, we need
to make sure that we're not compromising the foundations at the same time.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20091123/c52503c6/attachment.sig>