[6966] in bugtraq
Re: Vulnerability in 4.4BSD Secure Levels Implementation
daemon@ATHENA.MIT.EDU (abc@RALPH.ML.ORG)
Sun Jun 14 23:11:58 1998
Date: Fri, 12 Jun 1998 13:21:18 -0600
Reply-To: abc@RALPH.ML.ORG
From: abc@RALPH.ML.ORG
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <199806120100.SAA20983@passer.osg.gov.bc.ca> from "Cy Schubert -
ITSD Open Systems Group" at Jun 11, 98 06:00:07 pm
> The key word is "should" draw attention. Unless there is an
> application (or the system itself) that periodically checks for any
> change in status of a system daemon (like the change of a PID), I
> suspect that most sysadmins will not even notice that a system daemon
> has died and restarted. To help plug this vulnerability one of the
> following options might be desirable,
Many sysadmins in control of operating systems which have the
immutable/no-unlink flags don't use those flags at all.
> following options might be desirable,
>
> 1. Disallow sending signals to processes started from immutable
> binaries,
> except from init, e.g. during shutdown.
> Advantage: Improved security.
> Disadvantages: Administration may be virtually impossible and may
> break
> existing applicaitons.
While I agree that the signal issue is very messy, I don't think this
is a good idea. The obvious reasons include being able to keep a handle
on an out-of-control process. This would also be a great help to an
intruder who doesn't like his/her processes being killed.
> 1a. A variation of #1 except using a new "unkillable" flag which denotes
> immutable binaries that cannot be sent signals.
Same problems.
[...]
> 3. Replicate the immutable flag when a file is copied.
> Advantage: Some improved security.
> Disadvantage: Intruder can FTP a rogue daemon and run it instead.
Reliably implementing this would be impossible. The system has no
real way of knowing whether or not a file is being opened for the purpose
of its duplication, and making guesses at that could just lead to
big problems.
--
cstone <cstone@pobox.com> <abc@ralph.ml.org>
