[914] in bugtraq
Re: Request for discussion.
daemon@ATHENA.MIT.EDU (robert owen thomas)
Mon Feb 6 14:26:09 1995
From: rthomas@pamd.cig.mot.com (robert owen thomas)
Date: Mon, 6 Feb 1995 10:58:00 -0600
In-Reply-To: newsham@aloha.net (Timothy Newsham)
"Request for discussion." (Feb 6, 12:55am)
To: newsham@aloha.net (Timothy Newsham)
Cc: bugtraq@fc.net
hello, Tim--
just some of my "from-the-hip" thoughts...
== Timothy Newsham once wrote...
== priveledged programs
== --------------------
== trusted programs
== run in roots .cshrc,.profile,.login,.logout, etc.
== run in a cronjob
== run from system startup
== run from inetd
== suids
add to this list /etc/profile and the *numerous* config files for such things
as smail, etc.
== Changes
== -------
== - run network daemons with lower priveledges.
== discussion: Why are so many net daemons run as root?
hmmm... problems with the kernel here (particularly BSD-ish kernels). proc
groups not owned by root would make certain daemons unable to access kernel
space, perhaps...
== - 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.
difficult for administration, particularly when patching or updating a package
akin to smail. suggestion: run find with a -exec sum option. collect and
store in a truly safe place (e.g. a floppy disk). set up cron to run a
comparison job (e.g. run find for suid/sgid, perform sum, mount floppy,then
compare). perhaps link suid/sgid binaries to a common, *hidden* directory
for easy reference? use soft links to avoid easy detection.
== - 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).
i like this. in fact, i stress such things when i perform security audits.
caveat: do *NOT* store this database on-line. perhaps set up a secure,
stand-alone machine (be cheesy: ifconfig down) for storage of security
info.
== (As for nfs, nfs needs finer controls anyway).
very true. user bin is still, i believe, a security problem (as are some of
the other "system" accounts, e.g. adm, uucp, etc). nfs is bullet-riddled,
to be sure.
== - 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.
users would not be able to send mail. users would not be able to rlogin/remsh.
this is too sweeping a gesture, although the intent is good. suggestion:
write wrapper binaries around the suid/sgid commands. log activity. makes
a nice complement to some of the daemon wrappers.
== - 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.
very good thoughts. enjoy good horror stories? read the Morris and Bellovin
papers. the idea above needs no more support than that.
== Thus wrote Timothy Newsham
you obviously have an "eye" towards prevention. all too often, we hear about
the reaction, as opposed to the proaction. preventive medicine, i think, is
the goal. why wait until you have been cracked? unfortunately, it seems
that the prevailing wind in corporate America is "it will never happen to
me...".
good post, Tim.
regards,
--robert
--
o robert owen thomas: Unix consultant. MAILER-DAEMON. user scratching post. o
o e-mail: rthomas@pamd.cig.mot.com --or-- robt@cymru.com o
o vox: 708.632.5768 fax: 708.632.5694 o
o -- System Administrator's Dictionary -- o
o user (you'zer) n. 1 A waste of system resources; an unwanted load o
o on the processor(s) of a Unix system. 2 Someone who uses Caps Lock. o
