From owner-freebsd-security Thu Jul 2 07:05:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA26318 for freebsd-security-outgoing; Thu, 2 Jul 1998 07:05:35 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (root@ts01-55.waterford.indigo.ie [194.125.139.118]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA26254 for ; Thu, 2 Jul 1998 07:05:14 -0700 (PDT) (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id OAA00656; Thu, 2 Jul 1998 14:31:18 +0100 (IST) (envelope-from rotel@ginseng.indigo.ie) From: Niall Smart Message-Id: <199807021331.OAA00656@indigo.ie> Date: Thu, 2 Jul 1998 14:31:18 +0000 In-Reply-To: "Allen Smith" "Re: bsd securelevel patch question" (Jul 2, 5:54am) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: "Allen Smith" , dg@root.com Subject: Re: bsd securelevel patch question Cc: security@FreeBSD.ORG, njs3@doc.ic.ac.uk, dima@best.net, abc@ralph.ml.org, tqbf@secnet.com Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jul 2, 5:54am, "Allen Smith" wrote: } Subject: Re: bsd securelevel patch question > On Jul 2, 1:55am, David Greenman (possibly) wrote: > > Well, someone will have to convince me that delegating access on a port > > by port basis is necessary in the first place. I'd personally be happy with > > a simple privilege that allows binding to ports <1024. > > instead of setuid). Now, run a program via cron on a very frequent > basis that tries binding to the smtp, ssh, or other significant port > not run through inetd. This enables mail interception for smtp, > password interception for ssh, etcetera. With the exception of a Eh? If ssh/smtp/inetd bind to the port you won't be able to, no matter how often you try. And you won't be able to steal keys by hijacking sshd. I still agree with you for other reasons though, if an attacker creates a new service people might use it even though it isn't a legitimate service setup my the sysadmin. Whats wrong with a /dev/socket/tcp/XYZ acl type scheme? If the process has permission to read /dev/socket/tcp/83 then they can bind to port 83, you could make it a procfs type filesystem so all the ACL information was in memory for speed. Then you've got to save/restore state though. Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message