I'm wondering - should this report be marked as concerning also 'kdesu', i.e. "kdebase", due to it leaving behind a valid sudo ticket?
Also, I am curious to know - does 'gksudo' leave behind a valid sudo ticket, or is the ticket cleared afterwards? (And, consequently, if a ticket is left behind, should this report be marked as also concerning the package providing 'gksudo'?) ** Description changed: Binary package hint: sudo When we have the option "tty_tickets" in '/etc/sudoers', for each new terminal (tty) or pseudo-terminal-slave (pts) where we use 'sudo', we get a sudo ticket in '/var/run/sudo/yourusername/'. These are named "tty1", "tty2" etc. for tty's, and "1", "2", "3", etc. for pts's. Also, when we invoke a graphical instance of 'sudo' through e.g. 'kdesu', new pts's are reserved for this purpose. Applications started through 'kdesu' require _two_ pts's, and sudo tickets are assigned corresponding to the numbers of these pts's. This report affects, as I understand it, both 'sudo' and 'kdesu'. I do not know what is the behaviour of 'gksudo' in relation to this bug, so I don't know if this report should also affect it. Now, I will give three different scenarios in which 'sudo' or a graphical application requiring sudo capabilities can be run without a password, but when the user would _not_ expect to be able to do so. N.B.: Before each scenario, we must be sure we have no active sudo tickets in the above mentioned directory. Doing 'sudo su', 'rm /var/run/sudo/yourusername/*' and 'exit' in a terminal should be enough to ensure this. (I will start the examples from a clean desktop with e.g. no Konsole windows running. This is not completely necessary, as the _absolute_ numbers of pts's involved are not important to reproduce the behaviour.) Useful commands for demonstrating what happens are: 'sudo ls --full-time /var/run/sudo/yourusername/' 'ps au' (to show which pts's are in use, and by what processes) 'tty' (run e.g. in Konsole to show which pts we are on) Scenario 1: - Open a Konsole (or Yakuake). - Do 'sudo ls --full-time /var/run/sudo/yourusername', and give your password. - Do 'tty' - Do 'exit'. If you are in Konsole, this should close it completely -> now, start a new Konsole. If you are in Yakuake, it should do this automatically for you (spawn a new shell). - _Now_, we have closed the console we used. It _seems_ reasonable to expect that after we closed the console where 'sudo' was used, the sudo capability would expire. - Do 'sudo foo' or 'sudo ls --full-time /var/run/sudo/yourusername', and you can do this without giving your password. - If we again do 'tty', we will see that we are re-using the previous pts number, which is the cause of this phenomenon. Scenario 2: - Open a Konsole (or Yakuake). - Add a new terminal tab, and in this tab do 'sudo foo', giving your password. Do not close this tab. - Add a third terminal tab, and in this tab do 'sudo foo', giving your password. Now we have three tabs open in Konsole or Yakuake. - Close tabs two and three. (This will free two pts's.) (- In the first tab, just to illustrate, run 'sudo ls --full-time /var/run/sudo/yourusername', again giving your password.) - Run e.g. Adept or Synaptic, expecting to give your password. You should be able to do this without giving your password. - If we again do 'sudo ls --full-time /var/run/sudo/yourusername' in the first terminal tab, we will notice that two of the timestamps have the same time. What happens is that 'kdesu' will utilise the first two free pts's, which we just freed, and which, incidentally, happened to have valid sudo timestamps. Scenario 3: (Optional: - Open a Konsole or Yakuake.) - Run e.g. Adept or Synaptic, this time giving your password. Close it. - Open two new Yakuake tabs or Konsole windows or tabs. (- In the already opened terminal, do 'sudo ls --full-time /var/run/sudo/yourusername', which will give you the number of the valid sudo ticket.) - - In the second newly opened terminal, you should be able to run 'sudo foo' without giving your password. (IIRC, I have done this in the first sometime, possibly. It all depends on which pts number we are given.) + - In the second newly opened terminal, you should be able to run 'sudo foo' without giving your password. (IIRC, I have done this in the first new terminal instance sometime, possibly. It all depends on which pts number we are given. N.B. Normally 'kdesu' leaves behind only one valid sudo ticket, as in this scenario.) (- You can do 'tty' to verify that this is the same terminal that we saw had the valid sudo ticket.) I discovered this misbehaviour in sudo and applications that require sudo capabilities while investigating bug #72545 (and bug #50971). There are two separate issues here, as I understand it. Issue 1. As implied by the title of this bug, this gives the user a false sense of security under some conditions. Case 1.1: The user can (IMO rightly) expect that closing the terminal should _remove sudo capabilities_. It isn't intuitive to expect that a _new_ terminal instance should inherit previously affirmed sudo capabilities. When pts numbers get re-used and sudo tickets are not cleared, this is the resulting problem. Case 1.2: The user can expect that launching a graphical application that requires sudo capability should _always_ ask for the password. (I won't go into separate password caching capabilities of these, I fear it may be an entirely separate can of worms.) As previously, it isn't intuitive to expect that this should inherit previously affirmed sudo capabilities. This case isn't _necessarily_ all that damaging, e.g. in the case of running Adept or Synaptic, _but_ wrong nonetheless; however, we can imagine a situation where a graphically launched application requiring sudo capabilities could harm the user's system, and would _normally_ alert the user's attention by requiring the user's password. Case 1.3: Running a graphical application that requires sudo capability should _not_, in my opinion, leave behind a used sudo ticket that can be re-used in a terminal. Issue 2. This is at least a theoretical vulnerability in the system, if this _same_ user's account can be exploited. As I understand it, pts numbers are assigned to remote connections as well, so by coincidence a remote connection could receive a used but recently freed pts that has a valid sudo tty_ticket. Case 2.0: If this user's account (in the "admin" group) and _password_ have been compromised, this is a _non-issue_. If the password is out, trying to exploit _this_ behaviour isn't necessary. Case 2.1: If this user's account can be accessed otherwise, but the password isn't known, this would appear to be an issue. I don't think I can think of many scenarios where this could happen, but I imagine it is still at least a possibility. (Using 'tty_tickets' is in this case of course more secure than the system would be without it.) -- sudo option "tty_tickets" gives false sense of security due to reused pts numbers https://launchpad.net/bugs/87023 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
