As this issue seems somewhat hard to remedy completely, I decided to
comment on possible remedies separately.

It would seem beneficial that unused tty_tickets from
'/var/run/sudo/yourusername' should be cleared. More specifically, the
tickets for such tty's and pts's that _are not in use_ at any point in
time should be cleared.

Now, what process could be responsible for doing this?

A. The kernel and "devpts", which is responsible for assigning new pts's
at '/dev/pts/*'. It could be argued that this would be the right place,
to tackle the authorisation issue at a low level. It could also be
argued the opposite, that authorisation issues do not belong here, that
it is not the kernel's job to do things for sudo. This would mean that
this should be handled in userspace.

B. A root level "sudo daemon" that would keep an eye on tty's and pts's
on one hand and sudo's tty_tickets on the other hand. Whenever a
terminal or a pseudo-terminal is freed, the daemon would clear the
appropriate sudo tty_ticket for all users, and possibly make a note in a
log. (The tty's probably would need to be handled differently than the
pts's.)

C. For graphical applications requiring sudo access, the application
that granted the access could also clear the ticket when the sudo
capability isn't needed anymore. (E.g. 'kdesu' or 'kdesud'. It seems the
'kdesud' is used for caching the password given to 'kdesu'.)

D. A work-around is to use "timestamp_timeout=0" in '/etc/sudoers', but
this takes away a usability feature from sudo.

A couple non-working "solutions" follow:
E. "The command 'sudo' should be responsible for clearing the ticket." This 
can't be done, because sudo is not running when the terminal is freed.
F. "The terminal or 'bash' should be responsible." This can't be done because 
the terminal or the shell are not root-level processes, and so can't remove 
root-owned tty_tickets.

-- 
sudo option "tty_tickets" gives false sense of security due to reused pts 
numbers
https://launchpad.net/bugs/87023

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to