"All or nothing" Re: tlug: "Linux myths"

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Adrian" == Adrian D Havill <havill@example.com> writes:

    Adrian> Oooo, this really burned my bacon.

*snif*  Black pig, huh?  :-)

    Adrian> "Stephen J. Turnbull" wrote:

    >> It's interesting that every single statement in the Security
    >> section is at best questionable.

    Adrian> especially the C2 security statement-- which is just plain
    Adrian> false.

I don't think so.  If they got the rating, they got the rating.  That
is impressive, and my kudos to the development team.  But it means
nothing, because it was a lab test tuned to passing the test without
providing any services.  As soon as you start providing services, you
lose the C2 rating until the new configuration passes the test.
AFAIK, that means that every time you change the registry, you need to
recertify.  The C2 rating is aimed at military applications, not
business apps.  I would like the IRS systems to be C2 secure, but you
know they ain't....

A couple of comments.  First, Adrian's basic point is one that RMS has
made us all sick unto death of: System != kernel.  It doesn't matter
how secure the NT kernel is, the whole system (and that includes the
human admins; see Cheswick and Bellovin on "social engineering") is
what matters.

I'll grant that the "superuser" model has its problems.  But I can
only see two ways to improve it.  A user with a Linux boot disk, an
appropriate file system driver, and access to the console and a
removable bootable device can do anything they want to your system.
This means that there's really no point in _not_ having a root account
at the console.  But you can limit root access to the console.  We can
do this....  (I don't know if logind is provably secure in that
respect, but....)

The other strategy is to create more levels of access.  But the Unix
group mechanism is quite flexible, the problem is that using it is
either clumsy (forcing users to "log in" multiple times), or unsafe
(granting privileges to applications).  I don't see how to get around
that, though, no matter how you look at it, extra levels of access
implies extra authentication, or it's meaningless.

Second, in the NT approach to security they claim "any fool can
administer this."  But that's just wrong.  "Any fool" will not suspect
that they are subject to "social engineering" because "the system" is
secure.  Think about it: do you want the sysadmin uneducated enough to
go around doing the equivalent of carrying around fissionables in a
open stainless steel bucket?  Microsoft's claim is that you can do
that.  Security which is not well-understood and agreed to be
necessary by all admins is not security.

Third, the NT model means you trust your bosses completely.  They not
only own the keys; they're the only ones who know which keyholes to
put them in.  But even from the organization's perspective, that's not 
good; you want to be able to protect against finks at high levels as
well as low levels.  Having educated users (even) is one way to catch
bosses who go bad.  Think "JCO bucho"....

I wasn't surprised that they didn't mention PAM.

ACLs would be nice, it's true.  But it's not true that Linux doesn't
have ACLs.  codafs, for example, has ACLs.  So you could lock down a
minimal root fs real tight, and then most everything else would be
mounted via coda.  (Coda is probably nowhere close to secure, though,
and the quality of some of the code makes me shiver.)

We would, of course, like ACLs implemented in the VFS, and maybe even
deeper (although VFS might be sufficient if the /proc and /dev fses
had ACLs and all kernel requests went through /dev or /proc, which
could probably be done).

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."
-------------------------------------------------------------------
Next Technical Meeting: October 9 (Sat), 13:30   place: Temple Univ.
* Linux Internationalisation Initiative (Li18nux) speaker: Akio Kido
* Japanese TrueType Fonts                     speaker: Adrian Havill
Next Technical Meeting: November 13 (Sat), 13:30 place: Temple Univ.
* Network Security                               speaker: Steve Baur
Next Nomikai:  December 17 (Fri), 19:00 Tengu TokyoEkiMae 03-3275-3691
-------------------------------------------------------------------
more info: http://www.tlug.gr.jp        Sponsor: Global Online Japan