From owner-freebsd-security Thu Apr 4 19:37:12 2002 Delivered-To: freebsd-security@freebsd.org Received: from www.kpi.com.au (www.kpi.com.au [203.39.132.210]) by hub.freebsd.org (Postfix) with ESMTP id 7867B37B417 for ; Thu, 4 Apr 2002 19:37:06 -0800 (PST) Received: from kpi.com.au (localhost.kpi.com.au [127.0.0.1]) by www.kpi.com.au (8.9.3/8.9.3) with ESMTP id NAA45213; Fri, 5 Apr 2002 13:37:14 +1000 (EST) (envelope-from johnsa@kpi.com.au) Message-ID: <3CAD1BD0.8030008@kpi.com.au> Date: Fri, 05 Apr 2002 13:36:48 +1000 From: Andrew Johns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-gb MIME-Version: 1.0 To: Anthony Schneider Cc: freebsd-security@FreeBSD.ORG Subject: Re: a possible solution (re: su thread) References: <20020327163901.A33089@mail.slc.edu> <20020327171502.A33652@mail.slc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Anthony Schneider wrote: > oh, by the way, as another person mentioned to me already, this idea > is also quite akin to notions in the trustedbsd paradigm. he's right, > it is. the idea is that the tool would be extremely portable across > *NIX platforms. it would of course in no way stand above trustedbsd, > and that is not my intention. it would, however, somewhat mirror > access control policies in trustedbsd in userland. again, any ideas > on how to make this more flexible, secure, etc., are wolcomed. > -Anthony. > While doing some work recently, we came across sus - an interesting utility used where "many users need to run commands as root, but where sudo was too limited and su too powerful". http://pdg.uow.edu.au/sus/index.html From the homepage: SUS is a utility to allow a user (typically a system administrator) to run a single command as the super user. SUS reads a configuration file which determines if the user may execute the command or not. Some of the more advanced features of SUS are: * the configuration file is preprocessed as it is read by a "CPP style proprocessor." * an ability to define a class of system objects (users, groups, files, hosts or proccesses) by their attributes. * an ability to treat arguments passed to the target command as references to system objects and allow or reject commands based on the membership of such objects to predefined object classes. * the ability to run commands as users other than root. * the ability to run commands in background as session leaders. * the ability to let a user run a command as a target user if the invoking user can authenticate as the target user. I haven't tried compiling this on BSD, but it might get you some of the way there (or perhaps not). I'm interested in any comments on the code, etc. There are no copyright notices in the code or on the site, but I've emailed the author to determine the state of this. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message