Date: Thu, 13 Dec 2001 13:08:57 -0500 (EST) From: Igor Roshchin <str@giganda.komkon.org> To: piechota@argolis.org, wyldephyre2@yahoo.com Cc: security@FreeBSD.ORG Subject: Re: /etc/permissions Message-ID: <200112131808.fBDI8vi15855@giganda.komkon.org> In-Reply-To: <20011213123158.R49226-100000@cithaeron.argolis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <piechota@argolis.org> > To: Haikal Saadh <wyldephyre2@yahoo.com> > 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 admins. -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.firewall hosts.allow syslog.conf rc.conf (probably ?) inetd.conf periodic/ and periodic/* daily|weekly|monthly.local (not installed by default) maybe even mail/ and mail/*, or at least sendmail.cf probably kerberos* ... ... (feel free to expand) Igor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112131808.fBDI8vi15855>