Does it concern you if your browser can read your SSH keys? Do you think that on most personal systems, a user account is equally valuable as root?
You can talk endlessly about secure coding practices. Ultimately, your applications probably have holes, your system probably has holes, and your kernel probably has holes. For the most part, the problems get progressively more dangerous the further you get down the stack, but they start with the user account. If you run two processes as one user and one of them is hacked, it can generally run amok and do whatever it wants to to the other process.
Good ways to thwart this:
Capsicum. It's in FreeBSD, pretty much a system call (
cap_enable()) to drop
the current processes' privileges. This seems to work great for applications you
are coding and has already been done to some of the userland utilities on
FreeBSD. So in a nutshell, if you are running
gzip in a pipe, it doesn't need
to access files other than it's open file descriptors to stdin, stdout, and
stderr. You can either open a file for reading or pretty much immediately drop
its privileges before the exciting code comes into place, where there's more
likely to be some sort of buffer overflow. So, if you're writing something where
this is relevant, use it even if you have to
Jails, containers, or VMs. Not the lightest thing around, but you can make it work. You do have a lot of overhead having to maintain two "systems" and make sure what you want is on the target. This can be scripted, automated, and cleaned up, but may always be a bit overkill for some things. And as always, the easier security is, the more you'll do it.
Run a process as a different user ID. As long as your home is
this pretty much drops off the front door entrace to your SSH keys, your
cookies, your AWS keys, etc. This also is generally clunky and is not used as
much as it should.
raru. A user account doesn't need to have an
/etc/passwd or an
/etc/shadow entry to be used. It will simply pick random UIDs and they will
show up in
ps as that UID, not as some username.
One interesting behavior: If you
setuid() in a folder tree of
/chmod700/chmod755, you can poke around in
., even if you could never get
raru will work with local paths if it has explict access to
the current working directory. If it does not, it changes its directory to
raru effectively wraps your command and arguments. Unfortunately, it has to be
setuid to work. It sets a random UID and GID (both to the same) and runs the
raru will try to to stay in
. if 'everyone' has explict access to
it. It will attempt to
chdir(getcwd()), effectively, and if that fails it will
chdir("/"), instead. This means that if you are working out of a home folder,
raru shouldn't be able to access any of the files. You will have to copy them,
/tmp, and then run
raru from there. If you are unsure of
raru's cwd behavior, run
pwd and compare with
raru [program] <arguments>
raru does pass along the whole environment. So run
raru env to see
what this is. If you don't like that, run
env -i PATH=$PATH raru. You should
probably set that as an alias.
raru bash # Whole shell as a random user.
raru curl https://fishysite
xraru makes this slightly less bad by sandboxing the application with
and connecting to it with
vncviewer. It's slower, not resizable, not convient,
and currently only supports one application at a time. It needs a lot of work.
xraru chrome should load up Chrome and you can start poking away, and
only worry about the dozens of millions of lines of code beneath on the system
down, and not the dozens of millions of lines from the user up. Please note that
copy/paste buffers are sort of transparently handled, [possibly only shared when
the window is given focus]
This may or may not be secure enough for you. If you have passwords touch your
copy/paste buffers, you should be concerned.
We have to start somewhere, right?
xraru [X program] <arguments>
xraru only sets PATH and HOME environment variables. HOME is set to a
temporary directory that should be cleaned up afterwards. Cleanup is buggy (best
to kill with ctrl+c, not X'ing out of Chrome). Only one VNC connection is
allowed, so one compromised can't spy on the others, hopefully.
If you have
autocutsel installed, it should help manage copy/paste buffers on
the sandboxed side. If you have
dwm installed, it will run and probably make your
experience slightly better.
xraru thunderbird # Except you have to resetup your account every time.
xraru sxiv defconownsyou.jpg
xraru openoffice memo.ppx
xraru wine TA.exe
xraru QT_X11_NO_MITSHM=1 pybitmessage
# make install # THIS INSTALLS AS SETUID. THINK TWICE AND READ THE CODE.
These are probably far more than listed. However, at least be aware of the following:
alias raru='env -i PATH=$PATH raru'
raru, to work, is setuid
raru whoamia couple times to be certain that it's working.
raru ls .does not work if 'everyone' does not have access to
., anywhere from