[Security_sig] Pls review DLT Cap Doc 1.0 Security Section Draft

Philip Peake pjp at osdl.org
Fri Jan 7 11:08:46 PST 2005

Hi Emily,
    thanks for taking the time to look over this and write up your comments.

Let me set the context for this, which will explain some of the stuff =

you see:

The DTL project only really started working in about July of 2004, and =

set the rather ambitious objective of producing a 1.0 document to be =

published before the first LWE in 2005.
In order to meet that schedule we really had to have the content =

complete by early December (to get in all the tech-writing and review =

cycles).  To ensure that we would make that deadline we had to first =

talk only generally, in terms of capabilities required rather than fully =

specify what is required (specification is a much more labor-intensive =

and politically difficult task), and also reduce the number of areas we =

worked on to just those which were really indespensible. Harder topics =

were left for the 2.0 version (2005) and beyond. One of the harder =

topics was security.

However, as the document took shape, it became obvious that security =

really could not be avoided and it was starting to creep into the other =

areas in a piecemeal fashion. Thats no way to tackle security (as I =

probably don't need to say...), so the decision was taken to bite the =

bullet and start work on a security section, pulling together all of the =

security related items spread throughout the document into a single =

section, ensuring that they were not in contention, and restricting the =

section purely to capabilities. At some point we have to try to describe =

a full security architecture, but there was not the time to even think =

about that.

This section was pulled together in a very short time, mainly by Slav's =

hard work and some contribution from various OSDL resources and our =

tech-writer. This is actually its first review outside that small group, =

so in general I am (so far) pleased that people have not found bigger =

problems with it than they have.

Given that context, see my comments/questions inline below:

Emily Ratliff wrote:

> Hi,
> A few specific comments on the DLT security section:
> Data Protection Services - firewall sticks out as probably not =

> belonging in this section and indeed it has its own section where the =

> same words are repeated. Recommended references GPG and this OLS paper =

> http://www.finux.org/Reprints/Reprint-Halcrow-OLS2004.pdf
There was discussion on this topic. The firewall we are talking about =

here is not intended as a full-blown security firewall, more like one of =

the system hardening components. The primary firewalling would take =

place in the data center - desktop firwalls were seen only as secondary =

lines of defense. I think this would become clear when we develop the =

full security model/architecture. Personally I agree that this is =

probably misplaced where it is now.

> Directory Based Authentication - Recommended references winbind and =

> pam-ldap

> PKI on Linux is an interesting topic. When you say "Linux should =

> support PKI", what exactly is meant? OpenSSL provides the basic =

> implementation via command line. Is that considered sufficient to meet =

> this requirement? Last time I checked (a couple of years ago) none of =

> the GUI frontends to run a full infrastructure (creating, revoking, =

> and managing users and certificates) were really robust enough to =

> provide enterprise level infrastructure support. If I were trying to =

> conform to this spec, I would try to argue that OpenSSL is enough. If =

> that is not what you intended, I would recommend clarifying this =

> requirement.
I think we do forsee a full-blown PKI infrastructure as being needed =

(particularly for non-US markets). The infrastructure you mention =

(creation, revocation, management etc) is more of a data center function =

than desktop. We would need to work with the DCL group to ensure that =

our needs get covered there. On the desktop itself the need is for =

authentication/authorization based upon certificates - smart-card =

"login" for example as well as the file encryption mentioned below =

(which is probably just one example of a more general authorization scheme).

> Local Authorization - rather than saying local ACL database, recommend =

> pointing to http://acl.bestbits.at/
We can take a lookat this.

> Passphrase-based File Encryption - recommend referring to GPG again.
I think this was what was really being said, but not wanting to lock in =

to a particular technology at this point.

> X509 Certificate based File Encryption - are both Passphrase and X509 =

> file encryption mandatory, or would one of the two be sufficient for =

> complying with the spec? The way that it is written both are required. =

> Perhaps reference gpgsm
Excellent question - one which hopefully a better developped security =

architecture would answer.

> Even if you want to leave out anti-virus, I would recommend some type =

> of spam amelioration (such as spamassassin) since many of these =

> machines will be used to access email.
Anti-virus is complex. Scanning incoming e-mail and web downloads isn't =

too hard. A more general solution which would inspect file imported by =

*any* mechanism really needs OS level support.

Mail scanning (virus and spam) is a data-center activity in the =

enterprise (which is our target for this).

> However you get to the actual requirements, I really like this format =

> for presenting and explaining the requirements.
> Emily
> Emily Ratliff
> IBM Linux Technology Center, Security
> CISSP #51839
> 512-838-0409 (T/L 678-0409)
> emilyr at us.ibm.com
>security_sig mailing list
>security_sig at lists.osdl.org
>  =


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/security_sig/attachments/2=

More information about the security_sig mailing list