Date: Mon, 21 Feb 2000 12:07:46 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: "Chris D. Faulhaber" <jedgar@fxp.org> Cc: Tom Marchand <unixwiz@mediaone.net>, freebsd-security@freebsd.org Subject: jail, ipfw, Re: Controlled Network Access Message-ID: <Pine.BSF.3.96.1000221115906.81750E-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.10.10002191915040.3068-100000@pawn.primelocation.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 19 Feb 2000, Chris D. Faulhaber wrote: > On Sat, 19 Feb 2000, Tom Marchand wrote: > > > I would like to control which users can access tcpip utilities(ftp,telnet, > > etc) by using groups. I realize that this can be accomplished via the > > proper file permissions on each utility. This works but it will not prevent > > somebody from compiling their own ftp, telnet etc. My thought was to > > perform the authorization at the socket level. This would entail > > modifaction of the kernel to only allow root or a member of the tcpip group > > to open a socket. Does anybody know if this has been done or if it would > > even work? I originally had this requirement at work to lock down external > > vendors. Since we are an AIX shop it was quite easy. On AIX you must be a > > member of the system group to access network utilities. > > > > Although not at the socket() level, you may want to look into uid/gid > filtering via ipfw. As you point out, the ipfw uid-based limiting can do some of what was described. I use ipfw uid-based limitations on a jail/NAT box to limit which jail users can access my internal network from within the jail. Note that with jails in place, you can have strange uid-mapping problems, as different sections of the machine will map different uids to different ``users''. And since ipfw is not jail-aware, this can cause confusion. As I seem to be picking up some stewardship of the jail code, I'm considering a few changes for some future version of FreeBSD: - Allocate each jail a unique jailid, replacing jailname as the management identifier (as it can be changed within the jail unless jail.set_hostname_allowed is set, which is a desirable feature, but bad if you use that proc field to manage jails!) - Allow signal delivery to a jailid, resulting in the signal going to all process in the jail--good for shutdown/management stuff. - Access to jailid via ps(1) - jailinit(8), a ``first process in the jail'' with functionality similar to init(8), allowing for clean startup, shutdown of jails, binding vtys to jails in a sane way, etc. In particular, this would mean you could deliver an appropriate signal to the right jailinit to start an orderly shutdown of the jail from outside the jail, resorting to jailkill(jailid, SIGKILL) only when something refuses to die. - Nifty management utility for creating, destroying, starting, and stopping jails, possibly also at boot time. I'd also like to look at, but have not evaluated the technical feasibility of, adding a ``jail [jailid]'' behavior to ipfw. However, this would suggest putting jailid in ucred, and there are issues with doing this :-). I have extended ucred a number of times in the past for various projects--you get warnings from nfs due to union expansion, etc. Any thoughts on related improvements are welcome--most of my current round of improvements (security cleanups, documentation, etc) have gone into 4.0-CURRENT, with only a few things left (chflags fix is in progress). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services 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?Pine.BSF.3.96.1000221115906.81750E-100000>