Re: Vulnerability in 4.4BSD Secure Levels Implementation

[abc () RALPH ML ORG (abc () RALPH ML ORG)]

> 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>