[Security_sig] RE: DCL security feedback

Chris Wright chrisw at osdl.org
Wed Oct 13 22:38:56 PDT 2004

* Linda Knippers (linda.knippers at hp.com) wrote:
> The following consolidates feedback from Matt Anderson, Paul Moore
> and me.

Thank you for the feedback.  A bit of contextual background (in case it
wasn't clear).  A)  This version of the assumptions was a rough cut at
making it resemble english more than language we had adopted in the SIG.
As such, it needs some revision to accurately reflect what we had.  B)
The important part of these assumptions is getting clear definition that
traditional DAC security will or won't cut it.  Our general feeling is
that MAC is necessary, but we've worded the assumptions in a way that
suggest DAC is sufficient (esp. away from the edge).  We're hoping to
get some feedback from that point of view as well.

>  > Assumptions:
>  >
>  > Note that these assumptions are not for the edge, but for
>  > DB/application servers.
>  >
>  >
>  > 1) Unauthorized users are completely untrusted. The system should
>  > defend itself against unauthorized access.
>  >
>  > 2) Authorized users are trusted to do only what's authorized. This is
>  > well-known and should never overlap with administrative tasks.
> This should say something like:
> Authorized users are trusted to do only what's authorized for that
> specific user.  Different users may be authorized to do different
> things.  Unauthorized operations should be prevented.

How so?  Via traditional DAC methods with users and groups?  (I think we
agree on the need for separation, it's the mechanism that is challenging).

>  > 3) Authorized admins are implicitly trusted.
> There should be a provision of different levels of administrators
> with specific privileges.

Again, how are the privilege levels managed?  Via DAC or MAC methods?

>  > 4) Gaining physical access to the system gives same trust as if user
>  > were authorized as an admin.
> Do we need to make assumptions about physical security, either here
> or with 6.1?  User and admin actions on the system should to be
> auditable (is that a missing assumption?) and physical access
> to the data center (via card key or whatever) should be logged
> at a separate security office.

Audit records are not mentioned, and could certainly be added.  Point
here is there's a whole class of threats that include physical access to
the machine that we don't protect against.

>  > 5) The system may be attacked from the network.
>  >
>  >  5.1) Any attack from the network that results in unauthorized access
>  > should be stopped (classic example is root shell).
>  >
>  >  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.
> This assumption isn't very clear.   It could mean that authentication
> information provided over the network should be encrypted.  That sounds
> reasonable, but it could be read to mean that all network traffic
> should be encrypted, which isn't as reasonable.

I agree, it's confusing, and conflicts with other bits.  It needs more

>  >  5.3) Some method is in place to mitigate DoS attempts.  This could
>  > include firewalling.
> There's probably more than one method, unless "method" here
> includes policies, procedures, and tools.

So s/method is/methods are/ ?  Or did I miss something?

>  >  5.4) DDoS, well...
> Ditto.
>  >
>  >
>  > 6) Security perimiter is installation/application specific.
>  >
>  >
>  > 6.1) Systems containing high-value data are protected by their
>  > environment.
> Not sure what the terms "systems" and "environment" means here.
> Does this mean that if a computer system contains high value data
> that all of its security mechanisms are external to the computer
> system itself?  Does the system itself have no role?  That doesn't
> seem right.  Or does "systems" really mean an application that's
> deployed and the environment is the computer system(s) in which its
> deployed?  Or is this really just pointing out that physical
> security is important because of assumption 4?
>  >
>  >  6.2) Systems which are deployed on the edge may be directly
>  > responsible for their own network perimeter,
> Earlier there was a statement that the assumptions apply to 
> DB/application servers, not system on the edge, so this assumption
> seems out of place.

Yes, this is part of the conflict I metioned earlier.  Ed Reed pointed
out same concern.  Needs clarification, indeed.

>  > 7) When the DCL system is a cluster, the internal network is commonly
>  > inside a perimiter of defense (i.e. protected by firewalls).
> Not sure what "internal network" means here.  Is this the
> cluster interconnect, or whatever the cluster members are using
> for cluster-specific communication?  If so, then we suggest using the
> term "interconnect".  Ideally its at least virtually if not
> physically private to the cluster.  Or does it mean any network
> that's internal to a data center, which may include cluster nodes
> as well as non-cluster nodes?  If that's the case, its not clear
> what's special about the system being a cluster.
>  >  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.
> Right.  A network connected to a cluster member should be protected
> just as much as a network connected to a standalone system in a
> data center.
>  >
>  >
>  >  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.
> A cluster interconnect that isn't private has more issues than can
> be solved with cryptographic means.  If its sharing resources such
> as bandwidth, its susceptible to problems introduced by whatever
> systems or equipment that's sharing the network.  If something
> uses up all the bandwidth, then that's like DoS attack on the cluster.

Agreed on all counts.

>  > 8) The network address or addresses of the DCL system can be known to 
> the public network. (for example web/application servers).
> So a cluster that is not on the edge but behind the cluster firewall and
> the site firewall and in a locked room needs to have public IPs?  It
> seems like this one limits the ability to use an application proxy
> to sanitize requests.
> Re-reading this one, its not clear out what security goal they are
> trying to achieve with this statement.  The only one I can come up with
> is "don't rely on security thru obscurity" which I agree with, but I
> don't see how that translates into routable addresses.

Again, part of the confusion re: network connectivity.

Feel free to join the conf. call tomorrow.

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

More information about the security_sig mailing list