[Fwd: Re: [Security_sig] Security Gaps]

Mary Edie Meredith maryedie at osdl.org
Thu Oct 27 15:48:04 PDT 2005


Of the items Ed submitted, which are the ones 
that DCL as a group could do the most to solve
or for which DCL coul dhave the most impact if 
added resources were put behind solving it?

If they are going to happen on their own, 
those would not be on the list.  If the
problem is impossible to solve or work on
before projects are complete, that would 
not be on the list.



-------- Forwarded Message --------
> From: Ed Reed <ereed at novell.com>
> To: security_sig at osdl.org, Emily Ratliff <emilyr at us.ibm.com>
> Subject: Re: [Security_sig] Security Gaps
> Date: Sun, 16 Oct 2005 16:54:13 -0600
> A dandy list - thanks, Emily.
> 
> W/r/t I&A (your ending question below):
> 
> Full-peer interoperability with Microsoft (requires their help, unless
> we all ignore DCMA) (these are needs, not gaps - some of what's listed
> below may already be possible to one degree or another)
>  * ability to stand up LDAP and SAMBA services that fully accept and
> enforce MS / AD authentication and access control (meaning group
> membership) for file and resources (this should be just engineering)
>  * ability to stand up LDAP and KERBEROS services that are accepted as
> full peer domains with MS/AD - meaning that they can be introduced as
> trusted domains into a forrest, but in this case don't have to be full
> replication nor SAM token partners - would allow MS/AD domains and Linux
> domains to interoperate but not necessarily fully integrate (see next
> bullet)
>  * ability to stand up LDAP and KERBEROS services that are accepted as
> full domain participants, able to be either full domain controllers or
> backup domain controllers, or AD replicas, including Global Catalogue
> servers - so that Linux services are able to share the load for an MS
> /AD environment.
>  * ability for Linux SMB clients to discover, browse and authenticate
> to MS/AD or Linux-based domains without lots of nit-pickin' options to
> be set correctly - select an installation option "Integrate with MS/AD?
> - Yes/No" - and do it
> 
> Anticipate need for a SAML-based background authentication service that
> KERBEROS would support (by being an Identity Provider), so that single
> signon with web services can be federated with local and domain
> authentication chores.  This is NOT the "login" process, but rather the
> "I've already logged on, so don't ask me again - here are my derived
> credentials, now give me an appropriately authenticated and
> security-protected (integrity, confidentiality, non-repudiation)
> connection for THIS protocol (LDAP, DNS, SMB, portmap rpc, ide rpc,
> https, sftp, ssh, rexec, etc. using KERBEROS, SSL, SSH, TLS, IPSEC, or
> whatever is available as a secure transport).  Could almost be done as
> an adaptation of stunnel.
> 
> Looking at the LSPP development list, it sure sounds like all the
> Secure MLS networking research is going to get a work out... (hope
> you've got folks from Naval Research Labs and Naval Post Graduate School
> plugged into all that work...)
> 
> Common pluggable approach for supporting biometrics in PAM, including
> multi-factor authentication protocols (finger-prints PLUS smart card,
> for instance).
> 
> REPEAT:  common crypto supplier API framework, so that FIPS-certified
> crypto implementations, whether open source or not, can be leveraged by
> all the various packages - kernel crypto, libcrypt, cryptlib, glibc,
> gnu/tls, openssl in all its variations, whatever.  There's too many
> crypto implementations for customers to have to trust to be able to
> trust any of them.  Where's the OpenSSL FIPS certification, anyway? 
> And, what good will it do, if it's not GPL compatible?
> 
> Per-application, per-user, and per-server secret stores.  There's a
> proliferation of them and we need them to converge.  They need to use
> whatever (good) crypto is available on the box (FIPS 140, if possible),
> or hardware crypto (TPM, smart card, whatever), and they need to have
> certain enterprise-needed features:
>  * access by servers (Apache mod_ssl, DNS, LDAP, etc.) to their private
> keys without requiring login or password challenges to get them - via
> signed code, TPM etc., etc.
>  * key recovery for server identification keys and encryption keys
> (users, services, whatever) for disaster recovery and to support
> enterprise document retention standards
>  * APIs for applications that can be trusted to retrieve their OWN
> secrets, but not others - TPM gain may be a good starting point for
> this
> 
> I've probably fallen back into my habit of describing what I think is
> needed, without regard to what's available, but most of the things
> listed above represent "gotchas" that we've encountered, for which we're
> having to build solutions to work around not having them.
> 
> Ed
> 
> 
> >>> On Thu, Oct 13, 2005 at  2:53 pm, in message
> <OF09419247.8AFA3F9B-ON86257099.005B873D-86257099.0067CB0B at us.ibm.com>,
> Emily
> Ratliff <emilyr at us.ibm.com> wrote: 
> 
> > 
> > 
> > 
> > 
> > In no particular order, here are some Linux security gaps/wishlist:
> > 
> > Highly accurate open source static analysis tools (and all open
> source
> > projects making use of them)
> > Capability to run w/o root in a traditional DAC environment
> >       ala Solaris Process Rights Management
> >       Linux project: Olaf Dietsche's File system capabilities patch
> not
> > integrated
> > Integrated cryptographic framework -  single point of FIPS
> certification
> > Secure virtualized containment (not SELinux) ala Solaris
> Zones/containers
> > or HPUX Secure Resource Partitions
> >       this often gets punted to Xen, but there is an advantage for
> having
> > both types of virtualized containment available
> >       Linux project: vserver not integrated
> > Easy to use RBAC tools (not talking about RBACPP)
> > Encrypted file system with per file encryption
> >       Linux project: eCryptfs + others not integrated
> > Whole disk encryption
> > Patch risk assessment
> > MLOSPP compliance may become an issue in the near future
> > Kernel crypto api improvements -  asynchronous work underway,
> asymmetric
> > algorithms, GCM mode
> > 
> > I'd like to see IPSec be easier to set up and a centralized
> repository that
> > collects whether Linux IPSec and interoperate with various vendor
> VPNs and
> > the settings required for the VPNs that it can interoperate with
> (ala
> > monitor settings database or CDDB).
> > A tiny feature that I would like to see added to logcheck (may be
> there in
> > the latest release) is the ability to switch after a certain
> threshold from
> > telling me about attempts (for example, ssh login attempts)  from a
> certain
> > address to successes from that address. The attempts become
> uninteresting
> > and the successes are very, very interesting.
> > 
> > I haven't found anyone who cares but NIS+ is not available on Linux.
> > 
> > Other requests that we have received -  default umask 037, no world
> > writeable directories (/tmp) on filesystems/partitions with
> setuid/setgid
> > binaries and log files.
> > 
> > A key Linux weakness that affects other areas as well as security is
> a lack
> > of integration between components.
> > 
> > Ed, want to comment on I & A gaps?
> > 
> > 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
> https://lists.osdl.org/mailman/listinfo/security_sig
-- 
Mary Edie Meredith
Initiative Manager
Open Source Development Labs
maryedie at osdl.org
503-906-1942




More information about the security_sig mailing list