From owner-freebsd-security Sat Mar 17 2:40:56 2001 Delivered-To: freebsd-security@freebsd.org Received: from mr200.netcologne.de (mr200.netcologne.de [194.8.194.109]) by hub.freebsd.org (Postfix) with ESMTP id ADB0A37B719 for ; Sat, 17 Mar 2001 02:40:53 -0800 (PST) (envelope-from pherman@frenchfries.net) Received: from husten.security.at12.de (dial-195-14-235-121.netcologne.de [195.14.235.121]) by mr200.netcologne.de (Mirapoint) with ESMTP id ACQ21835; Sat, 17 Mar 2001 11:40:45 +0100 (CET) Received: from localhost (localhost.security.at12.de [127.0.0.1]) by husten.security.at12.de (8.11.3/8.11.2) with ESMTP id f2HAebK56557; Sat, 17 Mar 2001 11:40:37 +0100 (CET) (envelope-from pherman@frenchfries.net) Date: Sat, 17 Mar 2001 11:40:36 +0100 (CET) From: Paul Herman To: Gerhard Sittig Cc: Subject: Re: Multiple vendors FTP denial of service In-Reply-To: <20010316213716.D20830@speedy.gsinet> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 16 Mar 2001, Gerhard Sittig wrote: > > To bad a setusercontext() call couldn't be easily implimented > > inside of set[e]uid() (it's in -lutil not -lc). I see too many > > FreeBSD admins that believe that their proftpds and qmails are > > protected by the limits set in /etc/login.conf. > > Well, the latter is recommended to be wrapped up in a > softlimit(1) invocation. And the former - as well as any other > program - could be treated the same. > > If login.conf isn't easily applied one is still free to make use > of ports/sysutils/daemontools. Yes, there are many solutions, most of which have already been posted. Thing is, even if you created ports/sysutils/cluestick, many admins would still intuitively believe that limits imposed by /etc/login.conf apply to all processes. The reality that only a select few daemons use /etc/login.conf is admittedly counter-intuitive. Perhaps this is more of a job for TrustedBSD's MAC policies, but it Would Be Nice if resource limits were set along with (e)uid. What do others think? Like I said, this could be done by wraping setusercontext() into setuid(), but it starts to get yucky when mixing userland login_cap functions with a system call. I'd be willing to come up with a patch for this, if it weren't so darn ugly. Would there be a cleaner way to do this? -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message