[Security_sig] Assumptions in english/sysadm speak

Chris Wright chrisw at osdl.org
Wed Oct 13 23:02:23 PDT 2004

* Ed Reed (ereed at novell.com) wrote:
> Laughing out loud...
> Note - if "standard unix-based security techniques will be sufficient
> to
> 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 ;-)

Uhh, poorly configured? ;-))  I agree that some of the assumptions
below are at odds with traditional unix security.  Also, I think
the lines between edge, app server, and data base server are blurred
a bit.  However, I would like to thank Lynn for doing the work she did.
Especially in keeping an eye towards the end user in prep for those

> #3 (authorized admins are wholy trusted) is a reasonable statement,
> but
> 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
> requirement...
> 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
> vendor,
> not a consumer, so if you really only require a single root account
> for
> all your administrators, operators, database administrators, web
> server
> administrators and backup folks to use, I guess I've just been wrong.

We keep getting luke warm feedback on this one from both directions.
For one thing, the whole idea of the admin becomes cloudy, when you
consider some administrative duties may not require any root level
privilege, just read/write access to application specific areas.
We've not had direct user feedback, which is part of the problem.  We
hope to address that by early Novemeber.

Perhaps we should simply state an administrator shall have least privilege
to do required administrative tasks, and consider that the implicit trust
level suggests that something like sudo may be sufficient.  IOW, make it
clear that we expect different roles, but not in the MAC sense of roles.

Do you buy that?

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

You can prevent one class of attacks.  Those that include exposing
unecessary privileged services.  However, the statement is far to strong,
when considering the system is only running the required services.
I agree, all we can do it mitigate damage.  In the case of a buffer
overflow, this could mean turning a root shell into a DoS.

> #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
> solution
> 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.

This is arguably the crux of the issue with these assumptions.  I took
similar issue with these, saying that it's really pointing at MAC.  Are
we coming full circle?

> #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...

The cluster communications need proper segregation, I think that's
the point.  I'm not clear on why the cluster bits got added, actually.
But, even current clustering products support encrypted communication
and protect against trivial replay attacks...

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

More information about the security_sig mailing list