[906] in bugtraq
Request for discussion.
daemon@ATHENA.MIT.EDU (Timothy Newsham)
Mon Feb 6 03:36:51 1995
From: newsham@aloha.net (Timothy Newsham)
To: bugtraq@fc.net (BugTraq Mailing List)
Date: Sun, 5 Feb 1995 20:55:23 -1000 (HST)
Hi,
I drew up a list of some things I've been thinking about recently.
I would appreciate it if some of you would read it over and tell
me what you think about them. Right now its a very rough outline,
I didn't bother checking spelling, dotting all the i's etc.
Some of the ideas are probably unrealistic (as far as unix is
concerned) while others could be done (and some are being done)
today.
Tim N.
-----
scope of discussion
-------------------
attacks considered:
network user without local account running services on local machine
as priveledged or unpriveledged user or creating/altering/reading
files on the filesystem as priveledged or unpriveledged user.
local user changing from his user id to the id of another user
or reading/altering/creating files as another user.
priveledged programs
--------------------
trusted programs
run in roots .cshrc,.profile,.login,.logout, etc.
run in a cronjob
run from system startup
run from inetd
suids
Changes
-------
- run network daemons with lower priveledges.
discussion: Why are so many net daemons run as root?
- collect suid programs into common directory, or perhaps
a seperate directory for uid/gid. (both in src and bin form).
rationale: Increase awareness of security critical programs.
Make it easier to check all suid programs at once.
- collect daemons into common directory (done already - /usr/libexec in bsd).
rationale: see above.
- database of priveledged programs and dependencies. Ie config
files, temp files, directories, databases, etc.
rationale: Keep track of assumptions in security critical programs.
Avoid holes that arise out of changing an assumption (example
making utmp world readable). Make it easier for automated
checks (ie. world writeable directories like preserve and
msgs).
- per-process "trusted users" information. Only run binaries owned
by a trusted user.
discussion: simple way to do this is to put this functionality
in the shell. To be really effective the functionality would
have to be in the kernel exec code. This means the process
structure (or maybe the credential structure) would have
to have a uid list of trusted users.
rationale: reduce the risk of trojan horse attacks.
- non suid binaries owned by bin. bin considered priveledged.
ie nfs remaps bin as well as root.
rationale: better organization. Remove some of the "root clutter".
offload as much as possible from the root uid.
discussion: This might not be a good idea for the "trusted" binaries
since root will run these files thus making bin equivalent to root.
(As for nfs, nfs needs finer controls anyway).
- system list of users allowed to use suid and sgid. Suid
binaries not run if file owner not allowed to use suid/sgid.
rationale: reduce the ability to store priveledge on a filesystem.
- secure network services. authentication and encryption.
point to point encryption in socket layer? Change
services that rely solely on addresses for authentication to
rely on additional or other information. Replace
the priveledged ports model.
discussion: To replace priveledged ports a "trust" server could be
setup. This server would be on a well known port which would be
hard to get. Trusted hosts can be done away with or complemented
with private keys (one set of keys per "trust") or a public
key system (one secret key per host).
rationale: lower the risk of passive network attacks. Decouple
network priveledge (packet filter access, "priveledged ports")
from root priveledges.
- finer grained priveledges. ie. net -> raw sockets, priveledged
ports, etc. rlogin,rsh,etc become suid net.
net - raw sockets, priveledged ports, packet filters, routing tables
console - console and keyboard device. X servers.
fs - quotas.
uucp - modem
kmem - read kmem
rationale: Priveledged programs run with least priveledge required.
- uid/gid passing over sockets. Library functions to make
passing uids, gids and fds easier. Support for multiple
uids per process (there is already uid, saved uid and effective
uid). Ability to disable and reenable any of the uids.
(This can be done more effectively with a bitmask than
having a seperate "saved uid" variable). Ability
to specify how priveledges get inherited (maybe not necessary).
rationale: Add flexibility to security model. Make security
features easier to use. Move closer to a capabilities based
system.
- program to run a process with a lower priveledge. Run
programs in startup,cshrc,etc with minimal priveledge.
Database of programs/priveledge requires that would
be used by shell to lower priveledge before running
certain programs.
rationale: Programs run by a priveledged user don't
always need priveledge. Run with least priveledge.
Reduce the risk of trojan horse attacks.
- capability based security model. Passing of priveledges.
Ability to create new capabilities with a subset of
a capability as in VSTa. Disabling of priveledges.
Multiple priveledges per process. Security server for
giving away priveledges to certain programs (is this
possible to do in a secure way) to replace suid/sgid.
Security server for requesting priveledges.
rationale: Finer grained security model. Run programs
with least priveledge required. Reduce coupling
of filesytem security with system security. Support
the transition from host security to distributed
network security.