On Mon, Nov 30, 2009 at 15:09, Gene Czarcinski <gene@xxxxxxxxx> wrote:
Gene,
(Ahh... someone with a similar background...)
So the biggest question, to me, is to what standard do we start? There are plenty to choose from from DISA to NIST. I, personally, find the NSA's "Guide to the Secure Configuration of Red Hat Enterprise Linux 5" very good and might be a good place to start. I'm not saying that we do everything that is in the guide but maybe take the guide and strike things out that don't make sense and add stuff to it that does make sense.
Thoughts?
--Eric
Although I have read all of the messages on this thread as of the date/time of
this message, I am replying to this first message with all of my comments.
My background: I am currently retired but a few years ago I was still being
paid the big bucks for working on computer security and security assessment of
systems in US classified environments.
On the whole, I believe that Adam has outlined a good approach to the problem
of doing QA on security for Fedora!
General comment: I have read messages which claim that the approach is wrong
and that we need to look at things that a user can do rather than what a user
cannot do. I disagree. While the right approach for design/development is to
assume that a user can do nothing except what they are specifically authorized
to do, for security QA this needs to be turned around and the testing needs to
demonstrate what a user cannot do.
+1
On Monday 23 November 2009 17:08:31 Adam Williamson wrote:
> We can't do any meaningful security testing without knowing exactly what
> we should be testing for, in which packages. I believe Seth Vidal's
> upcoming proposal for covering 'major changes' may touch on this, but I
> doubt they'll cover exactly the same ground.
>
> So, if we are to have meaningful security testing in future releases -
> which QA believes would be a good thing - we need the project to define
> a security policy. We believe there's a genuine need for this anyway, as
> the introduction and widespread adoption of PolicyKit will likely lead
> to much more complex and significant potential changes in security
> posture than any previous change.
>
> 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.
A written description of the security policy is a must! Without it being
written down in simple english (with translations as appropriate), there will
be far too much subjective interpretation of what the policy is. I believe
spot's list is a good starting point for F13.
However, the policy should consider how Fedora should work with respect to
security and not how it does work as currently implemented. For example, you
cannot currently login as root from the gui (gdm) interface but you can login
as root from a virtual terminal ... is this the way the system should work?
Keep it simple (KISS) for the initial attempt. It will grow more complicated
all by itself as time passes.
BTW, the security policy should assume that a grub password is in use so that
a user cannot do something like disabling selinux by editing the kernel
command line. This should be tested by the security QA.
+1
>
> The second thing QA would require, aside from a policy with concrete and
> testable requirements, is a list of security-sensitive components to
> test. Obviously we couldn't test every package in the entire
> distribution for compliance with even such a simple list as spot's, and
> it would be a waste of time to try.
You definitely need to define a "reference implementation" that will be tested.
Security assurance testing is done on "as-built" systems ... not "as
designed"! It may be possible but is not practical to test everything. [or
will take so long that the release will no longer be supported]
Furthermore, I believe you should initially focus on a small subset of what is
in Fedora (perhaps gnome only) and with a selected set of services (servers).
At this point in time, considering all of the various windows implementations
(gnome, kde, openbox, xfce, etc.) will result in a lot of motion but little of
it in a forward direction. KISS!!!
...........
Given a written security policy for Fedora and a written description of the
"reference implementation" that will be tested, these need to be vetted and
"tuned" from comments.
After a reasonable amount of time, these documents/specifications should be
approved by the Fedora Executive Committee (or whatever). Any variation or
change, should require additional approval. There should be some independent
oversight of the security QA process to minimize subjective
(re)interpretation.
This will NOT make everyone happy. Sorry, but there is only so much resources
and you really do not want this to be a black hole which consumes everything
else.
Start small, grow, and learn. Two years from now, the security policy, the
reference installation/configurations, and the QA process for securtiy will
likely be very different.
Gene
Gene,
(Ahh... someone with a similar background...)
So the biggest question, to me, is to what standard do we start? There are plenty to choose from from DISA to NIST. I, personally, find the NSA's "Guide to the Secure Configuration of Red Hat Enterprise Linux 5" very good and might be a good place to start. I'm not saying that we do everything that is in the guide but maybe take the guide and strike things out that don't make sense and add stuff to it that does make sense.
Thoughts?
--Eric
-- Fedora-security-list mailing list Fedora-security-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-security-list
