On Fri, May 08, 2009 at 08:50:00AM -0500, Nicolas Williams wrote: > On Fri, May 08, 2009 at 11:03:35AM +0200, Casper.Dik at Sun.COM wrote: > > >They can also just debug your shells. > > > > But you can't do that on the "su shell". > > True, but they can debug all the user's shells and intercept the call to > su and make it execute a wrapper that will save the password. > > Apps like web browsers need to run with less than all basic privs, and > at a different label. They need to be sandboxed.
Worse, a compromised firefox doesn't even need to use /proc to debug my shells in order to trojan my environment and collect passwords. It can just edit (read: append to) my $SHELL's dot script files (e.g., $ENV in my case) to set PATH to have some dir as the first component where trojan wrappers (heh) for things like su(1) will be found. Most users would be unlikely to notice, and the trojans could remove themselves after sending off captured passwords and creating backdoors / installing rootkits. That said, I wish pconsole had been written using a very different approach, one where each xterm/rxvt/whatever execs an xkibitz-like program that puts the pty into raw mode and bridges it to the master side of another pty on the slave side of which is the shell/ssh/whaver instance that one wishes to control. Then the xkibitz-like program could insert input into the pty master without requiring any special ioctls, privileges, ... And this issue wouldn't have come up at all. >From an architecture point of view that seems cleaner than relying on a very obscure ioctl, and it'd give the app much more power too (it could capture all input/output, for example). Nico --
