Date: Tue, 8 Jul 1997 07:29:23 +1000 (EST) From: proff@suburbia.net To: robert@cyrus.watson.org (Robert Watson) Cc: sef@kithrup.com, security@FreeBSD.ORG Subject: Re: Security Model/Target for FreeBSD or 4.4? Message-ID: <19970707212923.12941.qmail@suburbia.net> In-Reply-To: <Pine.BSF.3.95q.970707153631.3248B-100000@cyrus.watson.org> from Robert Watson at "Jul 7, 97 04:05:07 pm"
index | next in thread | previous in thread | raw e-mail
> Unfortunately, that doesn't address the distinction between TCP and UDP
> services.. I'm not sure that is a huge issue, but it seems relevant. The
> formatting for this is looking more an more like an ipfirewall config
> file. I wonder if the similarities between the interfaces could be
> merged in some way?
>
> Also, since we're looking at putting permissions on port-binding, are
> there any other related resources or capabilities under BSD that are not
> limited by the current restrictions? Various types of socket
> communication don't appear to be.
>
> Robert
I wrote code to do just this (and more) over six months ago. It's still in
the GNATS database rotting as far as I know. Except from my ipfw man page
below:
[...]
uid user Matches if the packet is associated with a socket
created by user. The username any matches any user.
gid group Matches if the packet is associated with a socket
created by a user who at the time held the primary
or secondary group group. The group any matches any
group.
Socket credential rule-matching on packets varies
slightly according to the direction of the packet
being examined. This is necessitated, as to start
with we do not know if an incoming packet is asso-
ciated with a local client, is being forwarded, or
is to be handled by the kernel directly. First the
incoming packet is matched against all non-creden-
tial rules. If the packet is accepted, it then
passes to the protocol layer. If the protocol layer
is sucessful in locating a socket on which to de-
liver the packet, then the packet is re-examined,
passing through the firewall ruleset for the second
time. On the second occasion only socket credential
rules are matched against. If packet is accepted,
it is delivered to the socket, otherwise it is
dropped or rejected.
Output is somewhat simpler, as we immediately know
the socket credentials of the socket sending the
packet. This means we can match against the ruleset
in one pass.
Socket credential matches are not enabled unless
the kernel was compiled with IPFIREWALL_CREDEN-
TIALS.
bind Don't match this rule against packets, but against
the system call bind(). Only a specific set of in-
formation can be used for matches when this keyword
is specified: protocol, src, sport, interface, uid
and gid.
src is the interface address requested or 0.0.0.0
if no specific interface address was requested.
interface is the interface address, if requested,
unless the address belongs to a multi-cast group.
sport is the port requested, unless no specific
port was requested. In this latter case the source
port will be the port is the port allocated by the
system.
uid and gid are those credentials held at the time
of socket() creation, not those held at the instant
bind() was called.
The bind flag is not enabled unless the kernel was
compiled with IPFIREWALL_CREDENTIALS.
> On a related note, has anyone given any thought to making chroot() a
> user-accessible call? I haven't really looked at it, so am not sure why
> it can only be called by uid root programs. In terms of sandboxing (which
> seems to be popular these days for various applications), it would be nice
> to restrict programs to specific regions of the disk, etc. Especially if
> you are a non-root user developing programs that require special
> libraries, etc. Or if you want to run a restricted web or ftp server, but
> don't have root access (as hopefully would be the case with the lighter
> restrictions on binding ports <1024.)
this is why:
$ cd /tmp
$ ln /bin/sh sh
$ ln /bin/su su
$ mkdir etc
$ echo root::0:0::/:/sh >etc/passwd
$ chroot . /su root
# whoami
root
#
I submitted a (tiny) patch to ld.so that provides for a LD_CHROOT
environmental variable, which allows for automatic chrooting() after
dynamic symbol resolution. Any other way of doing this, apart from
source-level modification of the program to be chrooted is incredibly
painful and inherently insecure (not to mention grossly inefficient),
because your binary or your libraries have to be within the
chroot()ed zone.
PHK (FreeBSD core) decided to zorch the LD_CHROOT patch under the
basis that the efficiency gains could be realised by hardlinking
all your system libraries into the chroot()ed area. The mind boggles.
--
Prof. Julian Assange |If you want to build a ship, don't drum up people
|together to collect wood and don't assign them tasks
proff@iq.org |and work, but rather teach them to long for the endless
proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970707212923.12941.qmail>