kitty, terminals, consoles, VTs and TTYs -- Re: root "login" xterm to increase security?
On Sun, Sep 16, 2018 at 11:15:56PM -0400, grarpamp wrote: > Any search will bring basic stuff like > > https://insecure.org/sploits/xsecurekeyboard_fequent_query.html > https://www.techrepublic.com/blog/linux-and-open-source/three-features-you-may-not-know-xterm-has/ > http://tutorials.section6.net/home/basics-of-securing-x11 > https://www.reddit.com/r/openbsd/comments/83adcn/does_openbsd_x11_not_have_security_problems/ > > Whether xorg, wayland, xenocara, drivers, ttys, init, login, getty, > etc are receiving any level of scrutiny, audits, fuzzing, code > scans, etc. The ancient and obscure it is, the less people look, > and all the above are exactly that. > Even mashing kbd on a FreeBSD can throw console into > unrecoverable must kill state. > And people talk how trust X? Yes, Linux/BSD/etc tty/console/vt drivers need rewriting. On the bucket list, for the simple joy of it. https://en.wikipedia.org/wiki/Linux_console If interested in xterm perf, kitty kicks some serious goals - check its frame rates (comparo) in ncurses test: https://nick-black.com/dankwiki/index.php/Notcurses#Terminal_emulators https://sw.kovidgoyal.net/kitty/ (Although IMEHO, a vt ought be simplified, and support say tmux as a terminal multiplexer and disconnect/reconnect, rather than build this in as does kitty - although one can understand the temptation from the dev's perspective, elegance demands knowing when to step out of the way for the greater tmux good :).) Possible inspiration: https://en.wikipedia.org/wiki/Kmscon Post inspired by "Hacking the planet with Notcurses": Hacking the planet with Notcurses https://lwn.net/Articles/815475/ Author Nick Black has written an extensive book on the creation of textual user interfaces using the notcurses library; it's available under the Apache license [PDF]. "Many people asked how such a thing was useful. My usual response was that numerous devices don’t present a bitmap interface, that X11 GUIs run remotely over SSH are effectively unusable, that plenty of machines don’t have a GUI environment installed, that there are obvious applications for large outdoor displays, and that Sixel isn’t well-supported across different terminal emulators. It seems impossible in an age of gigatransistor graphics cards, but the text environment still presents perceivably less latency than most GUI toolkits."
Re: root "login" xterm to increase security?
0On 09/16/2018 11:15 PM, grarpamp wrote: > Any search will bring basic stuff like > > https://insecure.org/sploits/xsecurekeyboard_fequent_query.html > https://www.techrepublic.com/blog/linux-and-open-source/three-features-you-may-not-know-xterm-has/ > http://tutorials.section6.net/home/basics-of-securing-x11 > https://www.reddit.com/r/openbsd/comments/83adcn/does_openbsd_x11_not_have_security_problems/ > > Whether xorg, wayland, xenocara, drivers, ttys, init, login, getty, > etc are receiving any level of scrutiny, audits, fuzzing, code > scans, etc. The ancient and obscure it is, the less people look, > and all the above are exactly that. > Even mashing kbd on a FreeBSD can throw console into > unrecoverable must kill state. > And people talk how trust X? I take it as self evident that physical access can defeat any computer security strategy. One can limit what a naive and/or unprepared party can do with/to a computer they get their grubby fingers on, but a competent and properly equipped adversary - not so much. If the machine is off when the hostile party arrives, at least the data on an encrypted hard drive is safe. Until the next time an authorized user switches the machine on and mounts the file system, under the watchful eye of a hardware keylogger or flashed BIOS. :o) signature.asc Description: OpenPGP digital signature
Re: root "login" xterm to increase security?
On Wed, Sep 19, 2018 at 07:07:28AM -0400, John Newman wrote: > On Sun, Sep 16, 2018 at 11:15:56PM -0400, grarpamp wrote: > > Any search will bring basic stuff like > > > > https://insecure.org/sploits/xsecurekeyboard_fequent_query.html > > https://www.techrepublic.com/blog/linux-and-open-source/three-features-you-may-not-know-xterm-has/ > > http://tutorials.section6.net/home/basics-of-securing-x11 > > https://www.reddit.com/r/openbsd/comments/83adcn/does_openbsd_x11_not_have_security_problems/ > > > > Whether xorg, wayland, xenocara, drivers, ttys, init, login, getty, > > etc are receiving any level of scrutiny, audits, fuzzing, code > > scans, etc. The ancient and obscure it is, the less people look, > > and all the above are exactly that. > > Even mashing kbd on a FreeBSD can throw console into > > unrecoverable must kill state. > > And people talk how trust X? > > There is always a trade-off between security and usability. If not X (or > wayland, which I've only tinkered with), then what? I use tty programs > everywhere I can, e.g. mutt for email, irssi, etc - but gotta have > graphical UI sometimes. Also, tty is relatively space inefficient, specially on modern "high res" monitors where many xterms can be layed out to provide an efficient workspace - yet X (poor security) or Wayland (better?) is required to make use of all those columns and rows, and probably few these days would live without some GUI programs (browser, word processor, video/ tube viewer). When bitbanging your tty subsystem pretty well guarantees lockup, we can say we've a long way to go for robust "secure" systems … notwithstanding the hardware issues so visible today.
Re: root "login" xterm to increase security?
On Sun, Sep 16, 2018 at 11:15:56PM -0400, grarpamp wrote: > Any search will bring basic stuff like > > https://insecure.org/sploits/xsecurekeyboard_fequent_query.html > https://www.techrepublic.com/blog/linux-and-open-source/three-features-you-may-not-know-xterm-has/ > http://tutorials.section6.net/home/basics-of-securing-x11 > https://www.reddit.com/r/openbsd/comments/83adcn/does_openbsd_x11_not_have_security_problems/ > > Whether xorg, wayland, xenocara, drivers, ttys, init, login, getty, > etc are receiving any level of scrutiny, audits, fuzzing, code > scans, etc. The ancient and obscure it is, the less people look, > and all the above are exactly that. > Even mashing kbd on a FreeBSD can throw console into > unrecoverable must kill state. > And people talk how trust X? There is always a trade-off between security and usability. If not X (or wayland, which I've only tinkered with), then what? I use tty programs everywhere I can, e.g. mutt for email, irssi, etc - but gotta have graphical UI sometimes. -- GPG fingerprint: 17FD 615A D20D AFE8 B3E4 C9D2 E324 20BE D47A 78C7 signature.asc Description: PGP signature
Re: root "login" xterm to increase security?
Any search will bring basic stuff like https://insecure.org/sploits/xsecurekeyboard_fequent_query.html https://www.techrepublic.com/blog/linux-and-open-source/three-features-you-may-not-know-xterm-has/ http://tutorials.section6.net/home/basics-of-securing-x11 https://www.reddit.com/r/openbsd/comments/83adcn/does_openbsd_x11_not_have_security_problems/ Whether xorg, wayland, xenocara, drivers, ttys, init, login, getty, etc are receiving any level of scrutiny, audits, fuzzing, code scans, etc. The ancient and obscure it is, the less people look, and all the above are exactly that. Even mashing kbd on a FreeBSD can throw console into unrecoverable must kill state. And people talk how trust X?
Re: root "login" xterm to increase security?
On Thu, Sep 13, 2018 at 04:48:58PM +1000, Zenaan Harkness wrote: > So someone cracking into one's local user account via browser sploit, > one of the first acts would likely be to plant a password capture > script, e.g. wrapping sudo or something otherwise requiring password > entry. > > Once a password is obtained, via brute force or trojan, sudo gives > the entire system away. > > A convenience is some do "useradd me disk" - but again, any crack of > local account (even without password), now gives away all disks. > > Convenience vs security. > > > So what to do? > > > 1) delgroup me disk > "Important" data such as keyfiles ought be stored with no "primary > user account access", so group "disk" ought not be part of "primary > user"'s groups. > > Are there any other groups that "really ought" be removed from the > local primary user account? > > > > 2) Disable sudo and disable su > su (as well as sudo) again has the problem of password capture if su > or sudo is run from the primary user account after a sploit + trojan > planted. > > So, obviously, we need "clean" root logins, i.e.: > > - separate root account for admin/disk tasks > > - clean login, i.e. not via primary user account but using a clean > "login" process outside any user account > > And so logically, the immediate test is as follows (does not work for > me, gives me a .profile/.bashrc shell, not a login prompt): > > xterm -ls > > Note man xterm: > -ls >This option indicates that the shell that is started in the xterm >window will be a login shell (i.e., the first character of argv[0] >will be a dash, indicating to the shell that it should read the >user's .login or .profile). > >The -ls flag and the loginShell resource are ignored if -e is also >given, because xterm does not know how to make the shell start the >given command after whatever it does when it is a login shell - the >user's shell of choice need not be a Bourne shell after all. Also, >xterm -e is supposed to provide a consistent functionality for other >applications that need to start text-mode programs in a window, and >if loginShell were not ignored, the result of ~/.profile might >interfere with that. > >If you do want the effect of -ls and -e simultaneously, you may get >away with something like > > xterm -e /bin/bash -l -c "my command here" > >Finally, -ls is not completely ignored, because xterm -ls -e does >write a /var/log/wtmp entry (if configured to do so), whereas xterm >-e does not. > > > QUESTIONS: > > a) anyone know how to make xterm -ls give a 'clean' login prompt? > > b) is any presumption of a "clean" login prompt inside xterm, when > launched from a primary account xterm session, a folly? > > c) is there any other option for root in X, which could be considered > "resonably secure" in the face of a cracked local X using account? > > > 3) Qubes. > Isolate each activity into its own VM. > Notwithstanding hardware/CPU level firetruckery (another problem > which as grarpamp reminds us requires OpenFabs, OpenHW, OpenCPU etc), > isolating each activity, especially public facing activity such as > web browsing, appears to be a very reasonable proposition - this way > a browser crack means root access in the browser's VM, and not > automatically into the rest of the system (VM sploits > notwithstanding). References: https://www.openwall.com/lists/owl-users/2004/10/20/6 https://unix.stackexchange.com/questions/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login https://ubuntuforums.org/showthread.php?t=2241853
root "login" xterm to increase security?
So someone cracking into one's local user account via browser sploit, one of the first acts would likely be to plant a password capture script, e.g. wrapping sudo or something otherwise requiring password entry. Once a password is obtained, via brute force or trojan, sudo gives the entire system away. A convenience is some do "useradd me disk" - but again, any crack of local account (even without password), now gives away all disks. Convenience vs security. So what to do? 1) delgroup me disk "Important" data such as keyfiles ought be stored with no "primary user account access", so group "disk" ought not be part of "primary user"'s groups. Are there any other groups that "really ought" be removed from the local primary user account? 2) Disable sudo and disable su su (as well as sudo) again has the problem of password capture if su or sudo is run from the primary user account after a sploit + trojan planted. So, obviously, we need "clean" root logins, i.e.: - separate root account for admin/disk tasks - clean login, i.e. not via primary user account but using a clean "login" process outside any user account And so logically, the immediate test is as follows (does not work for me, gives me a .profile/.bashrc shell, not a login prompt): xterm -ls Note man xterm: -ls This option indicates that the shell that is started in the xterm window will be a login shell (i.e., the first character of argv[0] will be a dash, indicating to the shell that it should read the user's .login or .profile). The -ls flag and the loginShell resource are ignored if -e is also given, because xterm does not know how to make the shell start the given command after whatever it does when it is a login shell - the user's shell of choice need not be a Bourne shell after all. Also, xterm -e is supposed to provide a consistent functionality for other applications that need to start text-mode programs in a window, and if loginShell were not ignored, the result of ~/.profile might interfere with that. If you do want the effect of -ls and -e simultaneously, you may get away with something like xterm -e /bin/bash -l -c "my command here" Finally, -ls is not completely ignored, because xterm -ls -e does write a /var/log/wtmp entry (if configured to do so), whereas xterm -e does not. QUESTIONS: a) anyone know how to make xterm -ls give a 'clean' login prompt? b) is any presumption of a "clean" login prompt inside xterm, when launched from a primary account xterm session, a folly? c) is there any other option for root in X, which could be considered "resonably secure" in the face of a cracked local X using account? 3) Qubes. Isolate each activity into its own VM. Notwithstanding hardware/CPU level firetruckery (another problem which as grarpamp reminds us requires OpenFabs, OpenHW, OpenCPU etc), isolating each activity, especially public facing activity such as web browsing, appears to be a very reasonable proposition - this way a browser crack means root access in the browser's VM, and not automatically into the rest of the system (VM sploits notwithstanding).
