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... https://ubuntuforums.org/showthread.php?t=2241853