root "login" xterm to increase security?
Zenaan Harkness
zen at freedbms.net
Thu Sep 13 02:58:39 PDT 2018
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
More information about the cypherpunks
mailing list