Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: The reason for securelevel
From: Elad Efrat (eladNetBSD.org)
Date: Sat Jan 28 2006 - 11:37:48 CST
> Hm.. an "outrageous" proposition: in my view, this has become an
> overengineering of an initially simple securelevel concept.. _IF_
not over-engineering: over-complicating.
> there is a real need for more fine-grained control, why not go down
> the SELinux or grsecurity route?
you mean, implement a system that makes it a lot easier than it is
now for a user to lockdown his machine entirely? tls already mentioned
his concerns that the end-user dont always know what he's doing. these
systems you talk about proved one thing: very little people understand
them enough to configure them correctly, not to mention about the number
of people who will go through the trouble of configuring them.
let's keep it simple.
...unless of course you are willing to write a bsd-licensed
implementation of the selinux model to be included in netbsd, in which
case i *might* look at it.
> (I'm not saying to exactly copy their
> model, but just to make a system-wide security model)
suggestions like this are what i hate the most. suggestions on how
things can be done better.
right now the bsd security model is almost non-existant. we're lacking
file-system acls, we're lacking per-process capabilities and we could
also do user roles. but we have to start somewhere. i'm suggesting a
step-by-step move: first, we'll do the underlying work that will allow
us to implement finer-grained interfaces on top. this is what has been
discussed in this thread (if it wasn't clear) as well as my other work
on darwin-style kernel authorization.
unless you have a way to help by contributing *code*, pointing out
stuff that exists for years is not really helping.
> [I didn't mention FreeBSD's MAC as I'm not even briefly acquainted what
> it supports or not...]
freebsd has no MAC. freegpl has.
> As for the idea of keeping securelevel configuration in the file being
> "bad", I don't see why. The veriexec framework also keeps its signatures
> in a file.
really? forgive me for not being entirely familiar with veriexec.
have a look again at the entire thread, and then tell me of what
relevance the above suggestion really is. :)