Date: Thu, 11 Jun 1998 18:00:07 -0700
From: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca.>
To: [email protected]Subject: Re: Vulnerability in 4.4BSD Secure Levels Implementation
> Vulnerability in 4.4BSD Secure Levels Implementation
> This vulnerability is significant in that it allows an intruder to
> covertly modify running processes. The correct behaviour is to make
> the address space of these processes immutable. Although an intruder
> can still kill them and start others in their place, the death of system
> daemons will (should) draw attention on secure systems.
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,
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.
1a. A variation of #1 except using a new "unkillable" flag which denotes
immutable binaries that cannot be sent signals.
Advantage: May break fewer applications than #1.
2. Have init manage critical system daemons via /etc/ttys. When a
critical
daemon dies, automatically restart a new one.
Advantage: Administratively more palatable.
Disadvantage: Race condition possible to replace a system daemon
with a
rogue daemon.
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.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Open Systems Group Internet: [email protected]
ITSD [email protected]
Government of BC
