root "login" xterm to increase security?

[Zenaan Harkness]

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).