On 8/25/06, Elad Efrat <elad@netbsd.org> wrote:
> A rough assumption would be that 99% of NetBSD's userbase does not know
> m4 *and* understands TE/DTE enough to create their own policies; nor
> they should.

That's okay, if there's sufficient number of people to write those
policies.  Similarly, 99% of the Unix user population can't write
solid kernel code, for example a device driver.  That's okay because
we can copy bits for zero marginal cost from the people who can for
the people who can't.

> Part of what I'm interested in, beyond implementing yet
> another security architecture, is making it also as easy as possible to
> use.

Complex implementations can still have clear documentation and
easy-to-use interfaces.  For example, take a look at the new project
"wizard" for k3b or Nero.  Making CDs/DVDs is incredibly complex; see
cdrecord's argument list, for example.  But despite knowing next to
nothing about them, I can use k3b to copy them quite easily, by being
walked through a series of menus.

An NSA guy I talked to made the controversial (and unclassified)
argument that "the more complex the problem, the simpler the solution
has to be".  In other words, rather than try to figure it out and make
sure every t was crossed and every i dotted, apply brute force.  They
simply use seperate systems for classified and unclassified data (in
many cases).  While this works, it has its own penalties; you have to
have some controlled way of transferring data between the two, you
can't let people bring USB drives in to work, and so on.  It seems
unsophisticated to me.    Perhaps it needs to be simple because the
end-users don't have the expertise to consistently apply a more
complex solution.  I recall reading that during WWII, the Germans were
interrogating IFF systems on allied bombers, allowing them to detect
them at twice the distance they could with RADAR.  The allies quite
nearly took them out of bombers, because they couldn't be sure that
one person out of a hundred in a bomber group wouldn't forget to turn
them off when entering enemy territory.  When your users are virtually
untrained 18-year-olds, you have to take their limits into account,
which is why Humvees don't have a stick shift.  However, that's the
military and not typical of NetBSD admins.  Personally, I hate
automatic transmissions and I really hate those slow Sport-tronic
shifters.

As I understand it now, the NSA is now attempting to use virtual
machines with some custom transfer mechanisms for moving data between
them.

> If we provide a framework that is complicated to understand, configure,
> use, and debug, people will simply not use it, or use it "blind-folded".

I'm not arguing against ease-of-use being a good thing.  But the
problem is complex, and the solution is therefore complicated, but
that doesn't mean we can't write a simple layer over it that makes it
easy-to-use for most cases, and still provides very granular
lower-level implementations that an expert can tweak.

And if people just disable it, that's fine too; they're no worse off
than if it didn't exist.

> Exactly. Perhaps better illustrating my point would be to ask: what
> common security policy you can express using SELinux that you can't
> with (due to implementation of) kauth(9)?

I'm not that familiar with kauth, so I can't answer this.
-- 
"If you're not part of the solution, you're part of the precipitate."
Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484