On 09/13/13, Nick Holland wrote: > On 09/13/13 06:44, Donovan Watteau wrote: > > 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.
I was just trying to follow the mindset of not assuming that things will not fail, and instead building things so that if there's any problem it has less impact. Of course, a stolen private key is probably too much of an enormous fail in the first place. > 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. All right, so I think su better suits my use case. Thank you very much.
