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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
