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

[Chris Adams]

Once upon a time, Adam Williamson <awilliam at redhat.com> said:
> 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.

IMHO that's a backwards way of approaching security.  You will never be
able to define everything somebody should _not_ be able to do.  You
should always take the approach of defining what somebody _should_ be
able to do.

> Focussing on the relatively simple issues for now, we believe it would
> be reasonably simple to generate a list of all packages in the
> distribution that attempt privilege escalation. We believe this would be
> a list of packages that contain suid binaries, that invoke su, sudo or
> consolehelper, or that contain PolicyKit policies.

During the recent discussion, somebody mentioned there are also ways to
trigger events through dbus (I haven't looked down that path myself so
I'm not sure of the details).

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.