From owner-freebsd-security Fri Jul 3 02:30:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA20963 for freebsd-security-outgoing; Fri, 3 Jul 1998 02:30:02 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from beatrice.rutgers.edu (beatrice.rutgers.edu [165.230.209.143]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA20910 for ; Fri, 3 Jul 1998 02:29:57 -0700 (PDT) (envelope-from easmith@beatrice.rutgers.edu) Received: (from easmith@localhost) by beatrice.rutgers.edu (980427.SGI.8.8.8/970903.SGI.AUTOCF) id FAA08134; Fri, 3 Jul 1998 05:26:58 -0400 (EDT) From: "Allen Smith" Message-Id: <9807030526.ZM8133@beatrice.rutgers.edu> Date: Fri, 3 Jul 1998 05:26:58 -0400 In-Reply-To: Darren Reed "Re: bsd securelevel patch question" (Jul 3, 3:51am) References: <01IYXE91JSKI008EO4@AESOP.RUTGERS.EDU> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Darren Reed , rotel@indigo.ie Subject: Re: bsd securelevel patch question Cc: dg@root.com, security@FreeBSD.ORG, njs3@doc.ic.ac.uk, dima@best.net, abc@ralph.ml.org, tqbf@secnet.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jul 3, 3:51am, Darren Reed (possibly) wrote: > In some mail from Niall Smart, sie said: > > > > 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. > > you already have /dev/socket/tcp/XYZ using portals. > > why reinvent that wheel again ? There are three possible ways of doing things here: A. as Niall appears to be suggesting, have programs using the current syscalls, library routines, etcetera to do sockets, with permissions being determined by files B. use portals, with either editing programs to now use open or modifying the library, etcetera code to do this for them C. use another permissions mechanism (privileges, possibly via groups) A is a nice idea for configurability but is likely to be slow. B is also nice for configurability, appears possibly to be less slow, but will be rather headachy in either translating or library etc modifications. C is the option I'm favoring. > you (and others) seem very keen on doing this. maybe you should do > some more research about what's around now before taking this much > further. I've been trying to do so; thank you for opening up ftp access to the mount_portal code you've modified. The listen-only aspect is one thing that I've been looking at, for safety with rsh et al. Any suggestions as to other places to look at? -Allen -- Allen Smith easmith@beatrice.rutgers.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message