Travis H. wrote:

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

That's a good point -- but do we have to write a policy for every
application users are interested in running?

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

That is exactly what I am saying. Ironically, even though SELinux exists
for several years now, I still haven't seen a point-and-click tool for
generating policies (is this even possible if we want Good policies?)
for it...

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

I'm no NSA guy, but I did spend almost 3 years in the IDF. I can tell
you that from my experience, he's correct. Many of the problems you
would expect to see handled with technology are handled in a variety
of other ways in a military environment.

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

But it works. :)

(I could give you some examples of my own here, but I would rather
not for obvious reasons.)

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

A good point you're making is that we're developing an OS (mainly) for
(but not just) NetBSD admins and not the military -- which is why I
think SELinux-style solutions aren't that important for us.

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

That's how it works in other places...

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

First, I am not sure I agree with your reasoning that if the problem is
complex, the solution is therefore complicated as well. Anyway, judging
from what I know (and you are welcome to correct me, I'm not fluent in
Linux :) no-one has created such an "easy-layer" on-top of SELinux,
which, IMHO, may say one thing or another about it...

Another example is Systrace. Although it provides a way to automatically
generate a policy that does *exactly* what the program needs (as far as
that can be assured using syscall-based policies, without exporting
internal program context) not many people are using it because the
policy still requires human intervention after generating it, and as
strange as it may sound, not many people find it appealing messing with
syscall-based policies. :)

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

If the majority of people will disable it, then I don't think it has a
place in mainstream NetBSD. Unlike drivers which are "contained", such
framework is highly intrusive.

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

That is perhaps the most important bit of this discussion: is it *worth*
integrating a SELinux-like framework in NetBSD?

-e.

-- 
Elad Efrat