On Mon, 2009-11-23 at 17:55 -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. > Sure, I don't disagree, but I think we can take spots list and use it for the 'guest account'. Then you start picking things off the list as you move up the stack to 'university computer lab user (is that really much different from guest?)', to 'non-admin user', to 'admin user'. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
