[Security_sig] Security Gaps

Ed Reed ereed at novell.com
Sun Oct 16 15:54:13 PDT 2005

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
 * 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

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.


>>> On Thu, Oct 13, 2005 at  2:53 pm, in message
<OF09419247.8AFA3F9B-ON86257099.005B873D-86257099.0067CB0B at us.ibm.com>,
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
> 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
> integrated
> Integrated cryptographic framework -  single point of FIPS
> Secure virtualized containment (not SELinux) ala Solaris
> or HPUX Secure Resource Partitions
>       this often gets punted to Xen, but there is an advantage for
> 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,
> 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
> 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
> address to successes from that address. The attempts become
> 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
> 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

More information about the security_sig mailing list