Date: Wed, 27 Mar 2002 16:39:01 -0500 From: Anthony Schneider <aschneid@mail.slc.edu> To: freebsd-security@freebsd.org Subject: a possible solution (re: su thread) Message-ID: <20020327163901.A33089@mail.slc.edu>
next in thread | raw e-mail | index | archive | help
--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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020327163901.A33089>