[109] in linux-security and linux-alert archive
"Find all the SUID programs." Fine. So which *should* be SUID?
daemon@ATHENA.MIT.EDU (Andrew Cromarty)
Sat Mar 11 17:45:38 1995
Date: Sat, 11 Mar 95 13:18 PST
From: andy@distrib.com (Andrew Cromarty)
To: linux-security@tarsier.cv.nrao.edu
Reply-To: linux-security@tarsier.cv.nrao.edu
One of the irritating and dangerous results of Unix's 20-year-old
file-and-character computing model is that it leaves around thousands
of accessible static objects (files) with unspecified protection
requirements. Every month or so, some Unix wizard will admonish us on
one Unix/Linux mailing list/newsgroup or another that we should
"find / -perm ...." to locate all SUID files and inspect them for
legitimacy. But this begs the question. There's no place that
specifies which files *should* be SUID, or at any other permission
level. Worse, since every Unix variant has a different configuration
and introduces new files and directories and uses them in different
ways (e.g., "*should* /proc/mem be world-readable?"), even wizards
with lots of prior Unix experience can't know for sure that their
Linux system is secure, just due to permissions alone.
Our existing tools are pretty poor help here. As quick examples,
- Few man pages for properly-SUID programs state that this is a requirement.
- There's nothing in a program's source to specify that it should be e.g.
SUID or non-world-readable, and nothing in Makefiles or installation
scripts to automate implementation of such a policy.
- Even on a permission-secure system, installation scripts for new or
upgraded software can inadvertently walk all over our filespace and
trash its permissions without notification or documented justification.
- Programs like cops find file permission violations, but its default
specs may not match the specific permission requirements for Linux,
so it relies on the sysadmin to know them. It thus automates our ignorance
and our errors.
As a result, we're left trading lore on a list like this one, on an ad
hoc piece-by-piece basis, to provide these missing specifications. And
the security-spec learning curve for beginning sysadmins is
formidable, especially with Linux, which has a largely single-user
population, meaning almost everyone must become a sysadmin. You
_know_ the moderators of this list are going to spend the next few
years culling the same questions again and again about shadow
passwords, world-readable /dev/tty, ftp setup, etc. Even a (much-needed)
Linux Security-HOWTO or FAQ won't really solve this problem.
So, two questions:
1. What's a good Linux-specific spec for file permissions, against which
we can compare our "find" and "cops" output? I.e. what *should* be
SUID, SGID, world-unreadable, etc.?
2. What's a better solution to Linux security specification? E.g. what would
it take to build into Linux some facility (short of ACLs or capabilities)
that specifies and monitors access permissions, rather than requiring the
sysadmin to carry around complete knowledge of the entire system's security
requirements in his/her head? (It probably would need to handle
site-specific customizations too.) As one example, it would be
straightforward to construct an expert system to manage Linux security,
if we could simply codify the specification knowledge. In short, what
would be better than "cops plus a these-files-should-be-SUID list"?
asc
