Date: Tue, 29 Jun 2004 14:17:27 -0500 From: Guy Helmer <ghelmer@palisadesys.com> To: Kevin Lyons <kevin_lyons@ofdengineering.com>, chat@freebsd.org Subject: Re: "TrustedBSD" addons Message-ID: <40E1C047.7060708@palisadesys.com> In-Reply-To: <40E1B750.8030808@ofdengineering.com> References: <40E1A6C0.2040406@ofdengineering.com> <40E1B3B5.1020906@palisadesys.com> <40E1B750.8030808@ofdengineering.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Lyons wrote: > >> I can already see the security advisories for these things like we've > >> had for tcpwrapper, kerberos, heimdal, jail, openssl, etcetera ad > >> infinitum. > > > > > > How many of these were developed as part of BSD? One: jail. > > Well, point being that more layers/lines of code added, the more > potential vulnerabilities. I don't think we can say the FreeBSD or > TrustedBSD developers are any more exploit immune than other folks. > > >> Is this the right way to go? We're adding more bloat while openbsd is > >> cleaning itself and reworking kernal memory allocation to make > >> exploits near impossible. > > > > > > That's great work. Now, let's build on that so that the entire system > > is properly compartmentalized (i.e., MAC). > > But they are not doing that, they are ONLY adding some new > functionalilty. Am I misinformed or has any vm work been done on the > level of openbsd 3.4, beyond perhaps propolice. This new functionality (if used properly) would significantly mitigate the results of a vulnerability in any other part of the system. For example, think of an imap server running as root but that only can read and write files in areas of the system labeled for use by the mail system, and additionally not allowed to make outgoing network connections. Any exploited vulnerability (buffer overflow, race condition, etc.) in this imap server would result in trivial access to the system despite its running as "root". FreeBSD has been less vulnerable to heap attacks because of the different malloc in libc. I haven't paid attention to whether non-executable stack pages have been considered or committed by the VM gurus... > >> I dloaded 5.2 but haven't installed yet. I hope there is a way to > >> disable the MAC and other of these "trustedbsd features" that seem to > >> keep DARPA funded userland people busy. > > > > > > Is it so much harder to look a little more deeply at the sytem than to > > write a troll/rant? > > Not ranting/trolling. Thanks for the info, that is good. As I said, > i have not installed/configured it yet. I have been noticing feaping > creaturism in freebsd as of late so I was simply concerned about it. Good -- my "troll detector" is on alert today :-) > > Yes, MAC is a group of kernel compile options, and they are not shipped > > as part of the GENERIC kernel. From /sys/conf/NOTES: > > > > # Support for Mandatory Access Control (MAC): > > options MAC > > options MAC_BIBA > > options MAC_BSDEXTENDED > > options MAC_DEBUG > > options MAC_IFOFF > > options MAC_LOMAC > > options MAC_MLS > > options MAC_NONE > > options MAC_PARTITION > > options MAC_PORTACL > > options MAC_SEEOTHERUIDS > > options MAC_STUB > > options MAC_TEST > > > > Please take a look at the TrustedBSD implementation before ranting > about > > "DARPA funded userland people". There are good reasons why these > people > > were funded. > > Hmmpf. Perhaps it is because there was some leftover when theo lost > his money :). AFAIK, the TrustedBSD project was funded before Theo's DARPA money was stopped. I would be even more dissappointed in this incident if there were some connection (which I doubt). Guy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40E1C047.7060708>