Date: Mon, 6 Mar 2000 02:58:06 -0600 (CST) From: Igor Roshchin <igor@physics.uiuc.edu> To: security@freebsd.org Subject: named started by any user will be running until killed... Message-ID: <200003060858.CAA07208@alecto.physics.uiuc.edu>
next in thread | raw e-mail | index | archive | help
Hello!
I've got a situation when an ordinary shell user on a FreeBSD-3.4-RELEASE
box started the named server (by a mistake).
(Currently, this host is not running named)
The server wrote barked (to the syslog):
Feb 29 06:57:06 <daemon.warn> MYHOST named[22132]: limit files set to fdlimit (
1024)
Feb 29 06:57:06 <daemon.warn> MYHOST named[22132]: db_load could not open: loca
lhost.rev: No such file or directory
Feb 29 06:57:06 <daemon.err> MYHOST named[22132]: ctl_server: bind: Permission
denied
Feb 29 06:57:06 <daemon.err> MYHOST named[22132]: couldn't create pid file '/va
r/run/named.pid'
but did not exit.
Instead, it continued with periodic messages like:
Feb 29 06:57:06 <daemon.err> MYHOST named[22132]: bind(dfd=20, [XXX.XXX.XXX.1].53): Permission denied
Feb 29 06:57:06 <daemon.notice> MYHOST named[22132]: deleting interface [XXX.XXX.XXX.1].53
Feb 29 06:57:06 <daemon.err> MYHOST named[22132]: bind(dfd=20, [XXX.XXX.XXX.2].53): Permission denied
Feb 29 06:57:06 <daemon.notice> MYHOST named[22132]: deleting interface [XXX.XXX.XXX.2].53
...
going over all IPs (I have several IP aliases on that host) associated
with the network interface.
These messages were repeated in the syslog every hour until the named
was manually killed.
I am not sure if this created any problems for the system,
at least, I didn't see any obvious slowdown, or resource exhaustion,
but I would think there should be mechanism which would allow
to prevent such accidents.
Obviously, it can be done using "jail" and FreeBSD 4.x,
but even in FBSD-3.x there should be some way preventing users
from running system daemons.
I've been thinking about possible solutions:
1. to strip off the executable permissions for "others".
Possible drawback: since named can be run as "bind" in a sandbox,
this most likely will have side effects.
(I didn't check it, but logically expect such potential problem)
2. Making the file owned by "bind" (or nobody in case of httpd),
and then executable only by that user does not sound like a wise
idea to me (am I wrong ?)
3. ?
Just recently I was thinking if there should be some general
way of restricting daemons being run by users (on any port).
I would separate two parts of this problem:
a) preventing user from running it by an accident
(like in the recent example, when the user typed "named" by a mistake)
b) preventing user from running a daemon (e.g. one's own httpd on a different
port) intentionally.
(Note that in principle, removing daemons or restricting
access to them should be combined with with mounting users' home partition
as non-executable, so they cannot bring it from outside, but in my case
users need to run some scripts and small programs from their partitions)
May be I missed some existing mechanism ? I'd appreciate any pointers.
{\raw_stream_of_mind
Otherwise - how about some type of /etc/*.*rc file which will contain
the list of users who can run daemons, and would be checked
by the kernel each time a daemon program is started. Is there any criterion for
kernel to decide what is daemon and what is not ?
Listening to a port is not a reliable sign of a daemon [accepting
connections from outside], is it ?
Is there any situation when a legitimate user's process would
be listening on a port ?
Is daemon() (daemon(3)) a reliable sign of a daemon ? ...
}
Thanks,
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?200003060858.CAA07208>