Re: /etc/permissions

From: Igor Roshchin (
Date: 12/13/01

Date: Thu, 13 Dec 2001 13:08:57 -0500 (EST)
From: Igor Roshchin <>

> From owner-freebsd-security@FreeBSD.ORG Thu Dec 13 12:38:08 2001
> Date: Thu, 13 Dec 2001 12:36:18 -0500 (EST)
> From: Matt Piechota <>
> To: Haikal Saadh <>
> Cc: <security@FreeBSD.ORG>
> Subject: Re: /etc/permissions
> On Thu, 13 Dec 2001, Haikal Saadh wrote:
> > I just ran tiger on a 4.4R box today, and it mentioned that most the
> > files in /etc have perms that shouldn't be there...likewise, auscert's
> > unix security checklist recommended removing world read perms from quite
> > a few files. Have the permissions been overlooked, or is there some
> > design issue that I've missed out on? Common sense dictates that the
> > files in /etc/ should only be root accessible, right?
> Not really. If I run 'ls -l', ls needs to be able to read passwd to
> match the uid's on the inode to a username. If I can't read the file
> normally, ls (running as me) won't be able to either. I'd imagine there
> some things that could go without people being able to read them, but to
> me that's just security by obscurity, and doesn't really buy much. Except
> making it harder to do system maintenance without being logged in as root.

While some of the files , like /etc/groups and /etc/passwd,
need to be world readable for some programs to work properly,
several other files can be made unreadable for the users,
especially on a shell server.
Although hiding some files could be "security by obscurity",
some measures could create an additional difficulty for a malicious user.
Not allowing a user with a malicious intent to know how,
for example the system logging is done (that btw, requires making
at least some of the /var/log/ files unreadable too),
can prevent that user from preparing for the proper cover-up,
should one decide to exploit a local vulnerability.
Some users might not do that if they are afraid that you might be logging
things remotely, to a log-host.
This just one example. There are many other reasons too.

As we all know, sometimes, corporate requirements dictate to
introduce some "weakness" in the system (explicitely allowed
connections from a certain network, some ports opened for access
from a particular network, etc..). While a sysadmin should not
rely on those things being secure just because the config file (such as
/etc/rc.firewall) is not readable, if this creates an extra mile
for a malicious user to break in, it makes sense to implement it.

Probably, an optimal solution is to have those files under the group
wheel, and to make them group-readable for the convenience of the
-rw-r----- 1 root wheel 12345 Dec 32 19:87 /etc/rc.firewall
This way all admins who can read those files anyway by su-ing into root
can read them without actually doing that.

Good candidates for this change would probably be:
rc.conf (probably ?)
periodic/ and periodic/*
daily|weekly|monthly.local (not installed by default)
maybe even mail/ and mail/*, or at least
probably kerberos* ...
... (feel free to expand)


To Unsubscribe: send mail to
with "unsubscribe freebsd-security" in the body of the message