[Security_sig] Pls review DLT Cap Doc 1.0 Security Section Draft
pjp at osdl.org
Fri Jan 7 11:08:46 PST 2005
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 =
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 =
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:
> 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 =
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 =
> 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 =
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 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...
More information about the security_sig