Date: Thu, 11 Mar 1999 13:43:27 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Janos Mohacsi <mohacsi@iit.bme.hu> Cc: freebsd-security@freebsd.org Subject: Re: disapointing security architecture Message-ID: <Pine.BSF.3.96.990311134107.4815B-100000@fledge.watson.org> In-Reply-To: <Pine.GSO.4.05.9903111550220.13722-100000@bagira.iit.bme.hu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Mar 1999, Janos Mohacsi wrote: > On Wed, 10 Mar 1999, Robert Watson wrote: > > > > > > 3. The ideas of the /etc/login.conf was quite good. Wasn't it possible to > > > extend it for management (session, password, authentication)? I think > > > login.conf was quite strong in session and account management with > > > different classification of users. The only missing thing was the > > > sessiontime/idletime and sessionlimit management that could be done with > > > -- idled. > > > > I believe an idled is available via ports, if you haven't seen it yet. > > I know, but I think it should use the login.conf parameters... But it is > against the portability... Hmm. One would think an OS-specific module for determining policy in such a program would be a reasonable gesture in the name of portability :-). > > At one point in the past, I assembled a setuid manager that allowed policy > > to be set on these things. I never took it much further due to time > > constraints and other priorities (see below). > > You mean suidcontrol? That's the one. I had hoped to develop it into a decent interface for modifying system security policy; in particular, in such a way that it could then be mass-applied to a number of hosts rapidly (i.e., a cluster). Due to moving on to other projects and a sort of wondering whether it wasn't better just to use general-purpose tools, I haven't gone back to it. I may get a chance to look at it again more seriously in the near future. It also raises the issue as to whether it wouldn't be better to reengineer the setuid programs so they aren't setuid :-). > > If you have the time or energy to turn some of your suggestions into > > implementation (that is, perhaps a set of patches to the Makefiles to > > improve permissions, etc) that would no doubt greatly be appreciated by > > all parties involved. The send-pr mechanism is usually the best way to > > submit such changes+rationale, along with a CC: to -security documenting > > them to encourage someone with commit rights to deal with it, or at least > > raise some discussion about the changes. > > Ok. I will try it. > Janos Mohacsi > > Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ 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.990311134107.4815B-100000>