3 ms·

Good point. Nowadays, keylogging the master password is AFAIK easier for an attacker than tracing processes. This is still current: https://blog.invisiblethings

Good point. Nowadays, keylogging the master password is AFAIK easier for an attacker than tracing processes. This is still current: https://blog.invisiblethings.org/2011/04/23/linux-security-circus-on-gui-isolation.html https://blog.invisiblethings.org/2011/04/23/linux-security-c...

zaarn 9y ago
I wish Linux would implement a modern Secure Attention Mode (it has one but that kills all processes). It could be as simple as having a syscall that connects a process directly with the keyboard and does not let any other process intercept any keyboard input until the program lets go or times out (180s, after that the program isn't allowed to get SAM anymore for another 180s)
- yjftsjthsd-h 9y ago
  I feel that kernel-level handling would get messy. Just to name one thing that comes to mind: how would you handle multi-seat systems? Oh, or accessibility; say, there is no physical keyboard, just a touchscreen and onscsreen keyboard that you've just blocked from displaying. Yes, you could handle it, but by the time you've hit a few of these the code will be... inelegant.
  - zaarn 9y ago
    I've actually thought about this for a bit and it's not as complicated. If a physical keyboard is present, the program is assigned to the keyboard of the current user's seat (works with sudo since that only sets effective UID/GID not real UID/GID) Additionally, a program with root privileges (or a special CAP) can register itself as a HID in which case the SAM captures any HID's + keyboards of the current seat. Any complex setup would therefore be pushed out of the kernel but still provide reasonable security. An additional edgecase can be seen in debuggers which can be reasonably circumvented by having the SAM mode provide a few pages of memory that aren't mapped into any memory but the current process so a debugger can't read the password. A software keylogger would require strict root privileges to circumvent this system.

zaarn 9y ago

I wish Linux would implement a modern Secure Attention Mode (it has one but that kills all processes). It could be as simple as having a syscall that connects a process directly with the keyboard and does not let any other process intercept any keyboard input until the program lets go or times out (180s, after that the program isn't allowed to get SAM anymore for another 180s)

yjftsjthsd-h 9y ago
I feel that kernel-level handling would get messy. Just to name one thing that comes to mind: how would you handle multi-seat systems? Oh, or accessibility; say, there is no physical keyboard, just a touchscreen and onscsreen keyboard that you've just blocked from displaying. Yes, you could handle it, but by the time you've hit a few of these the code will be... inelegant.
- zaarn 9y ago
  I've actually thought about this for a bit and it's not as complicated. If a physical keyboard is present, the program is assigned to the keyboard of the current user's seat (works with sudo since that only sets effective UID/GID not real UID/GID) Additionally, a program with root privileges (or a special CAP) can register itself as a HID in which case the SAM captures any HID's + keyboards of the current seat. Any complex setup would therefore be pushed out of the kernel but still provide reasonable security. An additional edgecase can be seen in debuggers which can be reasonably circumvented by having the SAM mode provide a few pages of memory that aren't mapped into any memory but the current process so a debugger can't read the password. A software keylogger would require strict root privileges to circumvent this system.