From owner-freebsd-security Wed Mar 27 13:37:46 2002 Delivered-To: freebsd-security@freebsd.org Received: from slc.edu (weir-01c.slc.edu [207.106.89.46]) by hub.freebsd.org (Postfix) with ESMTP id 7768A37B416 for ; Wed, 27 Mar 2002 13:37:36 -0800 (PST) Received: (from anthony@localhost) by slc.edu (8.11.1/8.11.1) id g2RLd1u33246 for freebsd-security@freebsd.org; Wed, 27 Mar 2002 16:39:01 -0500 (EST) (envelope-from anthony) Date: Wed, 27 Mar 2002 16:39:01 -0500 From: Anthony Schneider To: freebsd-security@freebsd.org Subject: a possible solution (re: su thread) Message-ID: <20020327163901.A33089@mail.slc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable So, with all the discussion about the wheel group and su, I figured I'd come right out to the community about a project I've had in mind for some months, but which I will likely be able to do given that some time will be freed up in the next month or two (graduation :). The tool, quite simply, is an access "gate" to more security sensitive executables. The inspiration behind this comes from several places, but namely that UNIX permissions are not adequate for more elaborate user isolations schema. For instance, take su as an example: 1) only users in group wheel should be allowed to su to root. 2) certain users should not be allowed to su to any other account whatsoever. 3) certain users should be allowed to su to certain accounts, but not root. What this tool would do is be a wrapper, acting very much like sudo, but which would not run setuid root. Let's call the tool swrap for now. swrap would be setgid binary, and other security sensitive executables would be located in, say, /usr/local/swrap/bin. The actual executables would be symlinks to swrap, so for instance, su would be /usr/bin/su -> /usr/local/bin/swrap, with the actual binary in /usr/local/swrap/bin/su, permed gid executable only for gid swrap. /usr/local/bin/swrap would be setgid swrap. The actual swrap binary would determine binname =3D strrchr(argv[0], '/'); binname++;, and read its rc file, /usr/local/swrap/etc/swrap.conf for an entry like such: entry su { # individual users allowed to execute su ulist =3D [anthony, mark, sally, james, jessica] # groups allowed to execute su glist =3D [staff, users] # log specifications for specific users and groups log[ulist[anthony]] =3D [syslog] log[ulist[*]] =3D [syslog, "/mnt/lognfs/swrap.log"] ... # log all attempts by unauthorized users log[*] =3D [syslog, "/mnt/lognfs/swrap.log"] } The actual config language could be expanded upon greatly, possibly to include a list of allowed flags (so ulist[mark] could not su to sally, but could su to jessica, and ulist[sally] could su to mark, but not james...). The grammar is simple, and would not take up too many cpu cycles to parse for each invocation. This is, admittedly, very similar to sudo, but it would in effect be creating domains in which executables, attempted to be invoked by particular users/groups, could somewhat securely run, without the tool itself having to be setuid root. Possible other binaries to be included: ssh (and all of its s*=20 children), telnet, ftp, sendmail, lynx, ping, traceroute, ps, w...you get the idea. This is very much influenced by how more and more common open systems are these days, and how restrictions on basic utilities are a=20 necessity. If anyone has any input, criticism, encouraging words for someone who wants to write a tool that might be aggressively shot down for its likeness to another tool, please feel free to dump them on me. -Anthony. ----------------------------------------------- PGP key at: http://www.keyserver.net/ http://www.anthonydotcom.com/gpgkey/key.txt Home: http://www.anthonydotcom.com ----------------------------------------------- --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyiO/UACgkQ+rDjkNht5F3QlgCfU5OD6ETMi4zw1aCYFna0DuS1 8YIAn39Tcho+o/zweLXYMar/06vb7cr5 =mquT -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message