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