Linux security

Mon May 1 02:00:13 UTC 2006

On Sun, 2006-30-04 at 23:24 +0200, Alan McKinnon wrote:

> > I have a log file, say, that a cluster of applications writes to as
> > an audit trail.  I want only those applications to access it. 
> > (SELinux provides me with that level of control.)  And I want those
> > applications to be able to write to the end of the log file, but
> > not be able to read the file nor alter any contents once written.

> > You can hack a solution around that, but any such solution is just
> > that: a hack.

> Hmmmm, you have a point. I missed that one.

There's lots of subtle little use cases like that out there, sadly.  And
the UNIX model of "no privileges" or "can do everything you like" (the
superuser/clod divide) means you have to slather security hacks of your
own on top as a result.  Security hacks which are replicated
functionality and not as tested as well as something so fundamental as a
file system.  Finer grain is necessary -- hence the reason for things
like ACLs and SELinux and the like.

But then you make the other point below while I'll address too.

> Let's face it - security is hard. Really, really, fscking, OMG how 
> many things to I have to track? *hard*. I've thought up a bunch of 
> conceptual security ideas in my time, but quickly realized each one 
> would create a huge admin burden.

That's the other problem.  You absolutely have to have a balance between
functionality and usability.  This can be mitigated, however, by a
system which has "sane defaults" for common use cases.  Sort of "rigidly
defined areas of doubt and uncertainty".  :D

The Windows XP defaults are insane.  The system is kept wide-open by
default as if there's no security to be concerned about.  You can lock
down a Windows XP system tighter than any UNIX system without custom
enhancements (like SELinux, say) could ever accomplish.  It is, however,
a whole lot of error-prone work.

The UNIX defaults, however, are equally insane in the other direction.
You either have something pretty OK out of the box, or you're
micromanaging every little conceivable setting.  SELinux, for example,
if used correctly could outdo even the most tightly-locked Windows XP
box.  But you have to micromanage billions of little settings.  It's
almost impossible to use correctly as a result.

> > This cuts to the heart of the whole anti-Windows crowd's problem:
> > they don't actually know the platform they're criticising.  I hear
> > claims made here on this mailing list alone which are absolutely,
> > stunningly breathtaking in their sheer ignorance.  Usually from the
> > same people who shout "FUD!" at the top of their lungs whenever
> > anybody says anything negative about Linux, ironically enough.

> That's not an Ubuntu trait, it's a human one.

Agreed.  So is getting fed up with the bullshit, though.

> A large chunk of this list's users seem to be the under-25 crowd, with 
> heaps of idealism and not much experience. Think back to when you 
> were that age. I just did, and you have no idea how thankful I am 
> that Google wasn't around when I was 25...

<lie>I was never an ignorant idealist prone to long rants that proved
later to be 99.999999% incorrect.</lie>  ;)

> If you think this list is bad, try listen to the 
> Ferrari/Mclaren/Williams/Renault/Toyota fanboys on Sunday 
> afternoons :-)

Or go to Slashdot.  :D

> > Here's my gentle proposal to people (and not you, I stress Alan --
> > you seem to know enough about the Windows platform to have an
> > informed opinion): learn what you're critiquing so that those of us 
> > who actually do know it can't throw your absolutely staggering
> > ignorance back in your face with a sardonic laugh.

> Hmmm, you might want to tone down the harshness there just a wee 
> bit :-) Those same young fanboys would benefit more from a patient 
> explanation than from a flame, even though they will task your 
> patience to the limit.

I tend to reserve my patience for paid work.  Stuff I do in my spare
time for fun or speculation tends to provide me with a shorter fuse, I'm
afraid.  And sheer hypocrisy is one of my biggest hot buttons.  (I
should know -- I have plenty of hypocrisy of my own to test the button
with! ;))  People who blather total nonsense on a topic they know
clearly nothing about -- especially after screeching "FUD!" at the top
of their virtual lungs often on the same day just get my goat.  Badly.

> > A file system is essentially a hierarchical database.  ;)

> or like a hierarchical database where the only data type is a BLOB? 
> :-)

Well, I'm old-school.  I remember file systems with actual functionality
like record types, etc.  UNIX did a lot to damage the state of the art
in computer design that we're only slowly recovering from.

> > But yes, just because something can be done doesn't mean it should
> > be. This is why I've used the ultra-fine grained security under
> > Windows NT about five times in twelve years of working with it. 

> Which raises some harsh horrible questions:

> Is yours a typical case? And if so, is it really worth the effort to 
> maintain it?

I've usually been a systems man -- device drivers, APIs, etc. -- so my
use case isn't actually all that typical.  I imagine that people making,
say, PKI systems or accounting systems or the like would make far more
use of fine-grained security than I would on a typical job.  If it were
available and they didn't have to hack half-assed solutions on top of
inadequate systems.

> I can only imagine the code that implements that control, and the 
> amount of QA and testing that has to be done on it. I'd contend that 
> it's only because it's a security feature that that module even still 
> exists in the code base.

Well, actually, I can imagine the code and the testing for stuff like
this.  I worked PKI.  PKI has many of the same issues in reference to
key/certificate management, revocation lists, etc. and I know what we
had to do to test that crap.  But the key is that once you have a sane
architecture in place and tested up the wazoo, the testing is
incremental after that.  The key is "sane architecture".

> > (Incidentally this ultra-fine grained security isn't just on files.
> >  Another area where Windows NT as a platform is way ahead of stock
> > Linux, with or without fsattr and fsacl utils.  I can put that
> > security on sockets, named pipes, synchronisation primitives, etc.
> > -- anything with a HANDLE type attached to it.)  

> Interesting, I didn't know that

It's little-used functionality (mostly because developers are too lazy
to use it properly).  But I know it was kick-ass stuff for my PKI work
-- we locked down EVERYTHING tighter than you can imagine.

> > But the 
> > advisability of it wasn't my point.  My point was that total
> > ignoramuses were talking shit about how the UNIX security model is
> > finer-grained than that available under Windows.

> I think the fine-grained aspect makes for a (mostly) specious 
> argument. All modern OSes give a reasonable level of control within 
> their design specs. The question is how well is the chosen security 
> model implemented? Amazing fine grained control is worthless if it 
> can be easily subverted. This is far easier to do on Windows than on 
> *nix. Or put another way, the admin has to work his nuts off on 
> Windows to prevent it, but root can do it with relative ease.

Well, yes.  That's the "sane defaults" argument I advance above.  I
don't like the finicky levels that you have to go through to lock down
Windows (with always some niggling doubts attached).  But I don't like
the UNIX default level of coarseness either because it has several use
cases (the logging one, for example) which aren't adequately covered.
Adding ACLs/ATTRIBs helps, as does SELinux and similar mods, but then
you get into a situation that's harder to properly lock down than
Windows XP is!  :O

> Additionally, the Windows and *nix security models are fundamentally 
> different - Windows security is largely userID-based and *nix is 
> traditionally host-based. There is overlap and lately they are 
> converging but at heart a comparison isn't much use. Better to look 
> at infection rates per 1000 machines across the industry and see 
> which culture lends itself to creating secure systems. Currently it 
> looks like *nix wins this duel, maybe because the admins tend to be 
> individually better informed.

That, I would think, is the key.  To do anything serious under UNIX you
need more knowledge than a Windows box.  (The infamous lack of anything
resembling user friendliness under UNIX.)  As a result you'll know more
about what your system is set up to do and how to make it work.  Windows
is available to anybody with a half a brain cell to spare.  And sadly
half a brain cell is what a typical Windows system administrator
has.  :(

--
Michael T. Richter
Email: ttmrichter at gmail.com, mtr1966 at hotpop.com
MSN: ttmrichter at hotmail.com, mtr1966 at hotmail.com; YIM:
michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber:
mtr1966 at jabber.cn

"[Blacks] ... are inferior to the whites in the endowments both of body
and mind." --Thomas Jefferson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20060501/3cc31ac6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smiley-6.png
Type: image/png
Size: 796 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20060501/3cc31ac6/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smiley-2.png
Type: image/png
Size: 785 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20060501/3cc31ac6/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smiley-4.png
Type: image/png
Size: 822 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20060501/3cc31ac6/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smiley-1.png
Type: image/png
Size: 798 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20060501/3cc31ac6/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20060501/3cc31ac6/attachment.sig>