Re: Bind Overrun Bug and Linux (fwd)

[Alexander Kjeldaas <astor guardian no>]

On Sun, May 24, 1998 at 12:11:15PM -0600, Shaun wrote:
> > kernel to make the kernel panic when an ethernet device goes into
> > promiscuous mode.  Kind of like the James Bond theft-proof lotus, but it
> > will definitely set off the alarms if you're hacked and they start up a
> > sniffer that puts eth0 in promiscuous mode.
> 
> This is a good idea, but what happens if the machine is being put into
> promiscuous mode for other reasons than to sniff.  I run raw tcp/udp
> loggers that require it, so it would not work that good.
> 

This is exactly what makes the new 2.1.x capabilities much more useful
than BSD securelevel. You can remove the CAP_NET_ADMIN capability from
all processes except for your logger. This makes is easier to
implement a "least privilege" policy.

> > As an ISP, we used to give shell to all clients...but since most clients
> > signing up today don't know what telnet is, we no longer give them shell
> > access unless they ask for it.  Many times, an intruder will get in after
> > somehow sniffing a clients password from another network or social
> > engineering.  If the account they compromise doesn't have shell, it will
> > at least slow them down if not seriously limit the damage they can do.
> 
> I think a policy of NO shell access is a wise step to take.
> It takes away many risks, and many man hours of having to actually watch
> over the system.
> 
> > Hmm...I could try reading the source...but isn't this a job for
> > securelevel?  Does the kernel currently support, via securelevel,
> > prevention of module loading?  It would be nice if you could load modules,
> > then bump up securelevel, and no longer be able to.  Some things can't be
> > linked into the kernel.

This is possible in 2.1. Remove the CAP_NET_MODULE capability from all
processes. The capset system call will do it in a single atomic
operation - emulating *BSD securelevel if you want.

However, the capability needed to remove other capabilities
(CAP_SETPCAP) isn't enabled by default in 2.1 to make sure we didn't
introduce new security issues. This means that you have to do some
changes to your system to be able to use this functionality.

First of all, you need a patched init. Init is the only process who
has the CAP_SETPCAP capability and by default, processes started by
init will not inherit CAP_SETPCAP. You can either patch init to "bind"
a security level to runlevel, or you can let selected subprocesses
started by init inherit CAP_SETPCAP and work as "security daemon".

> > 
> > [mod: Securelevel is not properly enforced in 2.0.33. The word
> > securelevel doesn't occur anywhere in the 2.1.102 kernel. -- REW]
> 
> I thought securelevel was not properly enforced in any development or
> stable kernel.  I know there have been patches put out, Phrack included
> one in it's most recent issue.  Also, didn't Solar Designer include one in
> his secure-linux set?
> 

I think there are some patches in the 2.0.34pre kernels. Also, we have
a lot of securelevel patches in our GNSL distribution.

In GNSL, we have a securelevel ranging from 0 to 6999. root is allowed
to increase securelevel from say 2000-2999 when in runlevel 2. Init is
the only one allowed to bump securelevel over a 1000-limit. The
securelevel can only increased, even by init. The bootup sequence
starts in runlevel 2 and ends in runlevel 5, disabling kernel features
on the way.

More info at http://www.guardian.no/gnsl/


> PS, would someone with knowledge of *bsd securelevel systems please
> post something regarding this topic.

capabilities leaves securelevel-systems like OpenBSD in the dust ;-)

astor

-- 
 Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway
 http://www.guardian.no/