Why auditing and ACL's are important (was: audit_ids system calls)

From: Andrew van der Stock (ajv@greebo.net)
Date: Wed May 03 2000 - 10:21:45 EST

First off, I agree with those people who think that this patch does not fix
a bug in the 2.3 series, and should be a 2.5 feature. But the critics are
wrong to dismiss the project out of hand because it does not meet their
criteria for usefulness. It is very useful, and the lack of the feature is
preventing the use of Linux in real business and government sites *today*
and until the day this feature (and comprehensive and validated support for
it) is used by a variety of common turnkey apps (such as apache, databases,
mailers, etc) with appropriate file system support.

On a site that goes live in the next seven days, a client of a client of the
company I currently work for had to install NT servers to host what might
have been possibly hosted on Linux (the anonymized application set: a
groupware product, a database, middleware, web server, network layer fault
tolerance). The reason: no trusted audit trail. In certain business sectors,
such as banking, finance, telecommunications and insurance, this is

Auditing is helpful to anyone who has a host acting as a gateway to the net,
such as myself or Alan Cox or most of my friends. For example, primitive
file IDS functionality such as provided by tripwire or AIDE can be enhanced
by an audit trail saying that an object was *attempted* to be
modified/deleted/created by this *identity* at this time, with this syscall
with these arguments, and so on. A pager could go off immediately instead of
a few days (or a few hours in the case of the paranoid) into the future when
the next scheduled run of tripwire was done.

For web site owners (such as SourceForge), having more than just the old
Unix permissions for things like CVS trees, incoming ftp, mail spool, etc,
make a lot of sense. It also would make things like FrontPage a hell of a
lot more secure under Linux. At the moment, it is possible to have FP
extensions so badly configured that people with accounts on the same host
can modify other sites' root webs. This can be fixed with a bit of system
administration tom foolery, but it is so much simpler and more secure with

Linux will never be used by paranoid sites until at least what used to be
called C2 is reached (common criteria now replaces that old hoary chestnut
with something that actually allows the use of a network connection and
still have the potential to be secure). Used-to-be-B1 functionality is
*hard* to implement and maintain, but it is really helpful for sites that by
law must be paranoid. Linux is not in that space today. The B1-type space is
really small, and since I don't have a clearance, I've never done this type
of work, but it's an important space to most governments. In the manner that
Linux supports gigabit and FDDI cards, so it should support modular trusted
security. I don't use or like quotas, but some do, and they are useful and
appropriate for some sites (education, ISPs). I don't compile it in, but I
appreciate the fact that quotas are there if I (or a client) ever needs

Also, for the curious, security is mostly about drafting policy,
implementing it, auditing compliance with the document and then adherence to
the policies to prevent insecurities from developing. If you're interested,
the relevant standard for Australia/NZ/UK is AS/NZ 4444.1:1999 or BS
7779.1:1999. Costs about $AUD100. This basically helps most sites move -
with some effort and some months - from no security to a really quite secure
site and network. CC is *MUCH* much harder to achieve and is way more
expensive, and requires external validation of your efforts to achieve it,
so it's not suitable or desirable for the home network. But for some
organizations, it's the bare minimum required for them to store classified
data. Let's help Linux get into that space.

Don't think of modular security as something that could bloat your kernel if
you chose to compile it in, but as an opportunity to totally dominate the OS

Andrew van der Stock, Security Architect e-Secure Pty Ltd
"Secure in a Networked World" Phone: 02 9438 4984 Fax: 02 9438
Suite 201, 2-4 Pacific Hwy, Mobile: 0412 532 963
St. Leonards NSW 2065 Australia http://www.e-Secure.com.au/
ACN 086 248 419

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:12 EST