| Summary: | /usr/bin/slimlock from x11-misc/slim probably needs to be set SUID | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Denis Dupeyron (RETIRED) <calchan> |
| Component: | Current packages | Assignee: | Robert Pearce <bugs.gentoo> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | cyril42e, mgorny, proxy-maint, security |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
x11-misc/slimlock installed the binary SUID, so I expect this is simply overlooked in the build system for x11-misc/slim. I will patch the build system appropriately, unless security@ has any objections. (In reply to Ian Stakenvicius from comment #1) > x11-misc/slimlock installed the binary SUID I didn't know that. So it confirms my findings then. Thanks for taking care of it. Denis The change of SUID on slimlock in slim-1.3.6-r5 is causing my computer to hang after resuming when executing slimlock before suspend (slimlock& ; sudo pm-suspend). The keyboard and mouse are frozen: I cannot move the mouse/touchpad, cannot enter the password, cannot switch VT, cannot ctrl-alt-del or ctrl-alt-backspace (but power button halts the system nicely). I confirmed that this is due to the SUID flag. Is it really a security risk to allow switching VTs? I guess we are not supposed to have an open shell in a VT while working in X. Also when there are two instances of slimlock running it is not possible to enter the password to unlock the second one, and the only way is to switch VT to kill it (probably should have filed a bug in addition to improving my script to ensure that it never starts twice slimlock). |
When running slimlock from a terminal as a regular user, here's what you'll get: calchan@ddupeyron-dt ~ $ slimlock error opening console: Permission denied error locking console: Bad file descriptor error unlocking console: Bad file descriptor Other than that it seems to work OK. Looking at the source of slimlock.cpp you'll find: if(cfg->getOption("tty_lock") == "1") { if ((term = open("/dev/console", O_RDWR)) == -1) perror("error opening console"); And then, looking more closely at /dev/console: calchan@ddupeyron-dt ~ $ ls -als /dev/console 0 crw------- 1 root root 5, 1 Jan 30 12:47 /dev/console So it all makes sense. It's more than just a cosmetic issue, however, as a little further in slimlock.cpp there is: if ((ioctl(term, VT_LOCKSWITCH)) == -1) perror("error locking console"); This means slimlock is trying to disable VT switching but fails, which is a potential security risk. Indeed, with slimlock running you can switch back and forth to and from VTs. Setting slimlock SUID solves the issue. I don't know if this creates another security risk (which is why I CCed security@g.o), although I doubt. Maybe this could be made a USE flag in case it became controversial. Denis.