On 09/13/13 06:44, Donovan Watteau wrote: > On Thu, 12 Sep 2013 13:43:21 -0700, "Todd C. Miller" wrote: > >> On Wed, 11 Sep 2013 20:59:08 -0400, "Michael W. Lucas" wrote: >> >> > I've noticed that the sudo on OpenBSD seems to have !ttytickets set by >> > default. In other words, I authenticate sudo once on, say, ttyp4, and >> > all of my login sessions on all my other ttyp* have authenticated to >> > sudo. >> > >> > This, well, kind of surprised me. I'm sure you folks have thought this >> > through in much more detail than I have, but I can't find anything on >> > the rationale behind it. >> >> >> It's quite simple really, the version of sudo in OpenBSD (a patched >> version of 1.7.2p8) predates the change use tty_tickets by default. >> >> I've always felt that tty_tickets gives a false sense of security, >> though it is somewhat improved in more recent sudo versions where >> the tty is determined via sysctl() rather than by ttyname(). >> >> - todd > > Hi, > > Am I right thinking that sudo in base is still vulnerable to > CVE-2013-1776 for those who enable tty_tickets? > > BTW, I was thinking about the following use case: PermitRootLogin set > to "no", and a simple user who can only use public key SSH > authentication. "Defaults rootpw" is set, too. Then, I'd use sudo > when I'd need it (as it's suggested to use SUDO=/usr/bin/sudo for > ports, etc.). Then, let's say someone manages to get the private key > of my user (that's already a big problem of course, but it's an > unprivileged user who can't sudo without providing root's password).
non-root access to a machine is quite useful by itself, don't forget that. They may not be able to alter your machine, but it is still a useful tool to an attacker. > If the attacker logs in while the timestamp timeout is still valid he > can do whatever he wants with sudo without typing any password, right? > So I could set tty_tickets, but if it can't be trusted too much, > shouldn't su(1) be used instead for this use case? (or sudo with a 0 > timestamp timeout, but then I'd rather use su.) > > I hope this question isn't too stupid, but I'd rather ask. Some parts > of the FAQ suggest "setting up sudo", but with no particular setup, and > the one I was thinking about doesn't look good. > > Thanks. Your goal should probably be to be keeping inappropriate users out of your system; making things clumsy after they are in is not really the point, and could lead to poor administration. There is a reason there are options -- there is no one right answer for all uses. Look at your realistic threats, and decide what measure of risks and benefits you want. su wins in simplicity, but does mandate a shared password. If you are the only admin, that's not an issue. Nick.
