Date: Fri, 3 Jul 1998 05:26:58 -0400 From: "Allen Smith" <easmith@beatrice.rutgers.edu> To: Darren Reed <avalon@coombs.anu.edu.au>, rotel@indigo.ie Cc: dg@root.com, security@FreeBSD.ORG, njs3@doc.ic.ac.uk, dima@best.net, abc@ralph.ml.org, tqbf@secnet.com Subject: Re: bsd securelevel patch question Message-ID: <9807030526.ZM8133@beatrice.rutgers.edu> In-Reply-To: Darren Reed <avalon@coombs.anu.edu.au> "Re: bsd securelevel patch question" (Jul 3, 3:51am) References: <01IYXE91JSKI008EO4@AESOP.RUTGERS.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9807030526.ZM8133>