[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Full-Disclosure] yet another OpenBSD kernel hole ...



> From: "Doug Clements" <dclements@linkline.com>
> Date: Tue, 18 Nov 2003 10:26:37 -0800
> To: <jamesb.au@acm.org>, <tech@openbsd.org>
> Subject: Re: [Full-Disclosure] yet another OpenBSD kernel hole ...
> 
> ----- Original Message -----
> From: "jamesb.au@acm.org" <jamesb.au@ozemail.com.au>
> To: <support@mmicman.com>; <tech@openbsd.org>
> Sent: Tuesday, November 18, 2003 6:55 AM
> Subject: Re: [Full-Disclosure] yet another OpenBSD kernel hole ...
> 
> 
>> Because it's a local exploit, it can only happen if a malicious user has
>> access to the system anyway.
>> 
>> Aside from that, perhaps a new security feature can be introduced into
>> OpenBSD to (hopefully) stop these things quickly even if they are not
> known
>> about in advance.  One possible way is to introduce a feature like
>> /etc/shells called /etc/rootbins which lists the programs that may run as
>> root.  The scheduler can use an assembler routine that does a quick check
>> for programs running with uid=0, and if so, something not in /etc/rootbins
>> gets killed and root is notified.  That's pretty nasty because it would
> hurt
>> system performance, but it's a last ditch resort maybe - I have NO idea if
>> it would be workable.
> 
> Or just copy what netbsd is doing with only running binarys that match the
> md5 given to the kernel at boot (or compile) time.
> 
> --Doug
> 

What I did several years ago when faced with a similar requirement was to
modify the kernel and the various script interpreters to only run binaries
and scripts marked system immutable. The kernel was further modified to
disallow init lowering the securelevel through anything but a reboot and
disallow setting the system immutable bit in high securelevels. This avoids
the overhead of calculating digests and prevents attacks that modify
existing binaries (causing a denial of service under the digest method). It
also makes system maintenance impractical and is ultimately not worth it for
most common deployment scenarios in my opinion.

jonathan
-- 
+++ Jonathan Rozes, Manager, Information Technology, Vinton Studios