[Security_sig] Assumptions in english/sysadm speak

[Chris Wright]

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 the
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 revised
> assertions,

<snip>

> I have added some sample interpretations to the assertions to see if we
> 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 defend
> 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. Standard
> unix-based user definitions and authentication procedures are sufficient
> 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 structured
(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 root
> access is provided to all administrators.  No additional safeguards are
> 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 physically
> isolated in a computer room and therefore tightly controlled provides
> sufficient control against unauthorized access.
> 
> 5) The system may be attacked from the network. Standard well-designed
> firewall systems and unix-level security procedures are sufficient to
> 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 access
>  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, with
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 to
> 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 vulnerable
to attacks from compromised front-ends.  If so, it's not much different
from having database on public network (except the attack route requires
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     http://lsm.bkbits.net

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