DragonFly kernel List (threaded) for 2003-12
:-On [20031208 23:12], Ryan Dooley (dooleyr@xxxxxxxxxxxx) wrote:
:>I don't have access to the perforce trees (I'm normally not a developer)
:>but I think it would be cool if DFly could give the OpenBSD folks a run
:>for their money :-)
:I'm not sure if that would be useful for the DragonFly project, I'll let
:Matt decide on that. But everything pretty fundamental, such as the
:TrustedBSD project, detracts us from reaching the goal DragonFly is
:striving towards, namely: easy and fast clustering, scalability, and
:Of course, Matt should correct me if I totally misinterpreted something,
:but this should be one of those 'wannahaves' to be put on the backburner
:for a while.
:Also, note that we're not trying to compete with OpenBSD here. The
:projects' aims lie in way different directions.
:Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
Trusted BSD is an interesting project but I don't like the mess it makes
in the FreeBSD-5 kernel, and it does not solve the most basic problem of
bugs in system calls creating root holes.
NetBSD or OpenBSD (I forget which) has a system call masking feature which
is probably more effective.
I don't dislike the idea of having compartmentalized security, I just
think it is far safer to have it all in one place... e.g. like a loadable
'filter' on the syscall messages (and VFS messages, and DEV messages),
instead of having to go in and modify individual system calls, filesystems,
and so forth.
If the only way to get into the kernel is via a syscall message, and the
only way to access a filesystem is via a VFS message, and the only way to
access a device is via a device message, then that is where we code up
our security mechanisms.