[Security_sig] Assumptions in english/sysadm speak

Ed Reed ereed at novell.com
Wed Oct 13 12:19:39 PDT 2004

Laughing out loud...

Note - if "standard unix-based security techniques will be sufficient
defend against" hostile users, network attacks, unauthorized users,
broken applications, cross-site scripting attacks (against backend
databases), and so forth, where have they been all my life ;-)

#3 (authorized admins are wholy trusted) is a reasonable statement,
leaves open the question I asked of the list earlier, which is - is
every admin completely trusted not to do anything they're not
authorized to do?  Or is every admin explicitly authorized to perform
whatever they want to do?  I don't think that's a real DCL
I think DCL is MOST likely to require SOME separation of duties among
administrators of different pieces of the system.  But then, I'm a
not a consumer, so if you really only require a single root account
all your administrators, operators, database administrators, web
administrators and backup folks to use, I guess I've just been wrong.

#5 is just plain wrong - you can't prevent attacks - attacks will
The question is what will happen when they succeed, and they will.
Refer to history, at least as far back as the Morris worm.

#5.1 clearly requires some least privilege enforcement outside the
scope of the broken application - a mandatory policy of some flavor.
I think it's entirely appropriate.  I'm not convinced that any
that doesn't at least do what Immunix' Subdomain does (I don't think
you have to go so far as SELinux Type Enforcement) will effectively
defeat escallation of privileges in broken applications that have
delivered over a root shell.

#7 and #7.1 seem to be self-contradictory to me.  If the database
backend in a cluster has to treat the cluster network as hostile, then
it must assume that there may be packet sniffers watching traffic
between front-ends and the backend database, so the database
traffic should be encrypted to avoid inadvertent disclosure of
patient privacy or customer personnally identifying information.
Never mind credit card numbers.

Perhaps you mean with #7.2 that the cluster interconnect isn't
the "untrusted network", but that the public interfaces on the
cluster may be hostile.  I can buy that.  Hate to think we need to
encrypt cluster interconnect data at this point...

>>> Chris Wright <chrisw at osdl.org> 10/13/2004 1:12:37 PM >>>
Bringing this onto the list.

----- Forwarded message from Chris Wright <chrisw at osdl.org> -----

Date: Tue, 12 Oct 2004 17:21:56 -0700
From: Chris Wright <chrisw at osdl.org>
User-Agent: Mutt/1.2.5i
To: Lynn de la Torre <ldelatorre at osdl.org>
Cc: chrisw at osdl.org 

Meta-comment...To me, the purpose of these assumptions is to justify
choice of not requiring Mandatory Access Controls (or even better, get
everyone to disagree with the assumptions and get them to then decide
they need MAC).

* Lynn de la Torre (ldelatorre at osdl.org) wrote:
> Chris,
> Here is the message I just told you about.  Please look at my
> assertions,


> I have added some sample interpretations to the assertions to see if
> can translate a little bit for systems and/or security admins on IT 
> staff. Do these make sense? Did I state anything incorrect on this?
> - - - - - - - - - - - - - - - - - - - - - -
> 1) Unauthorized users are completely untrusted. The system should
> itself against unauthorized access. Standard unix-based security
> techniques will be sufficient to defend against unauthorized access.

In other words, there's no such thing as an unauthorized user.

> 2) Authorized users are trusted to do only what's authorized. This is

> well-known and should never overlap with administrative tasks.
> unix-based user definitions and authentication procedures are
> to ensure that authorized uses of the systems occur.

It's also likely that the interface is removed from direct access.  So
the database server is accessed by a program that a) authorized the
user, and b) fed the database server a request that is highly
(only perhaps parameters are controlled by user, like which item is
being looked up, or whatever).

> 3) Authorized admins are implicitly trusted. Standard unix-based
> access is provided to all administrators.  No additional safeguards
> needed beyond this since there is implicit trust.
> 4) Gaining physical access to the system gives same trust as if user

> were authorized as an admin. The fact that the systems are
> isolated in a computer room and therefore tightly controlled
> sufficient control against unauthorized access.
> 5) The system may be attacked from the network. Standard
> firewall systems and unix-level security procedures are sufficient
> prevent attacks.

This is where I start to have issue.  We should probably take this to
the list.  It's the slippery slope that points towards MAC, as far as
I'm concerned ;-)

>  5.1) Any attack from the network that results in unauthorized
>  should be stopped (classic example is root shell).

I'm not sure about this.  Part of the point (as I understand it), is
that the system is not near the perimeter, so we're saying it has
controlled access via multiple-tiers of application.  The reason I say
that, is that generically stopping remote root shell is hard.  Esp,
only unix permission model.

>  5.2) Any attack from network that results in pseudo-authorized
>  access should be preventable with crypto (stops snooping
>  passwords).  However, no protection once keys are lost.

What is pseudo-authorized access?

>  5.3) Some method is in place to mitigate DoS attempts.  This could
>  include firewalling. 
>  5.4) DDoS is a consideration, but not universally needed for all
> industries/etc.
> 6) Security perimiter is installation/application specific. Standard
> unix-level security techniques are sufficient to set the security
> perimeter to meet the installation/application needs.

I don't quite grok this one.

> 6.1) Systems containing high-value data are protected by their
> environment.For example,  Applications and/or database servers rely
> primarily on those software packages to prevent unauthorized access
> high-value data.
>  6.2) Systems which are deployed on the edge may be directly
>  responsible for their own network perimeter.

IOW, they are directly on the net?

> 7) When the DCL system is a cluster, the internal network is commonly

> inside a perimiter of defense (i.e. protected by firewalls).
>  7.1) Individual components of a cluster should still consider the
>  network as hostile, e.g. database backends should resists attacks
>  from compromised front-end systems.

This is the question.  Do we consider the database backend as
to attacks from compromised front-ends.  If so, it's not much
from having database on public network (except the attack route
an extra level of sophistication).

>  7.2) Communications between cluster member should be adequately
>  protected, e.g. by using a separate network for a HA cluster
>  interconnect, or by cryptographic means.
> 8) The network address or addresses of the DCL system can be known to

> servers that touch the public network such as web servers.

Linux Security Modules     http://lsm.immunix.org    

----- End forwarded message -----

More information about the security_sig mailing list