
Restricted Shells: Sometimes Persuasive but Usually Fallacious - twakefield
https://gravitational.com/blog/ssh-restricted-shells/
======
LukeShu
The article claims that things like Bash's restricted mode are ineffective. It
gives the example:

    
    
        parent$ bash --restricted
        child$ cd ..
        bash: cd: restricted
        child$ pwd
        /home/rjones
        child$ bash
        grandchild$ cd ..
        grandchild$ pwd
        /home
    

where the escape is that 'child' was able to create the non-restricted shell
'grandchild'. If you think that properly configuring a restricted bash shell
is a simple as executing `/bin/bash --restricted`, then you need to read the
manual. The restricted shell can execute arbitrary programs _in $PATH_ ; to
deploy a restricted Bash shell, you'll need to construct a PATH with
whitelisted programs that it is safe to execute. The restricted Bash cannot
adjust PATH, and it cannot execute programs outside of PATH.

Something like:

    
    
         $ PATH=/etc/restricted-bin bash --restricted
    

where /etc/restricted-bin contains symlinks to or stub-wrappers for programs
that the restricted shell should be able to use.

~~~
russjones
Maybe I did not provide the best example, but the point I was driving at is
that the restrictions here are at the application level and not at the system
level.

If you take the approach you are taking, similar to ForceCommand, you have to
make sure none of the commands in your PATH allow code execution. For example
git, vim, less, awk, and find, all of which I use on a daily basis, can all be
used to re-launch a restriction free bash.

Once you remove all the commands you have to, how much of a shell do you have
left?

~~~
LukeShu
_> but point I was driving at is the restrictions here at the application
level and not at the system level._

Your point is well-taken!

I'm obviously not privy the the conversations you've had with potential
customers, so I'm not entirely sure what they're asking for. But (IMO) the way
to think of a restricted shell is to think of it as a shell that can't do
anything, except for a small list of narrowly defined tasks. Thinking of it as
a normal full shell, with "unsafe" things disabled, that's a losing game, as
you note.

------
schoen
Restricted shell escapes are a common topic in CTFs and they can be a very
interesting test of one's knowledge of shell and Unix details. It's not clear
to me whether people who commonly construct these challenges think that a
restricted shell can actually be safe or not.

(It's clear that to _attempt_ to have a safe restricted shell, you have to,
among other things, whitelist rather than blacklist executable programs,
studying each one individually to learn whether it allows arbitrary code
execution or not.)

~~~
lvh
It also doesn't help that when some people say restricted shell they mean
"actually like bash, running on a real system", or more of a debugging console
(a bespoke REPL a la Python's stdlib's cmd module). I'd happily believe you
can secure something like the latter, and I don't think it's worth the expense
of securing the former.

(But also, if you give people an anodyne shell like that, what's the point? If
all you can do is peek and poke at metrics then maybe you just wanted better
instrumentation?)

------
verdverm
From the article:

> Another form of system hardening you can use is containers.

Let's not forget the 8k+ vulns on the top ten docker images, and the general
security implications of containers.

Like, let me run my data export from inside the publicly downloaded container
that connects to the database and hasn't been locked down, because who
actually audits and hardens their containers or manually configures their
docker runtime?

~~~
lvh
Where does the post tell you to do that? If anything it tells you a) spend a
lot of time paying attention to what sounds like what you might call "the
general security implications of containers" and b) it also tells you that
systems like K8s mean that you may not need to run said container to your prod
database.

Saying that one of the senior engineers at Gravitational "is unaware of the
general security implications of containers" is a pretty bold claim.

~~~
verdverm
Under alternatives, Containers and Schedulers, 3rd section from the end

~~~
lvh
There's no "Containers and orchestration" section, but there's a "Containers
and Schedulers" which is what I assume you meant. Here's the full text of that
section:

\----

 _Once you have a containerized application, you can use a container scheduler
like Kubernetes or Docker Swarm to run it on your production hosts. Container
schedulers provide a well defined API to access the status of the container
like its state and logs. This means users only have access to the running
programs over a well defined API._

 _Because containers are self-contained images with everything they need to
run, developers do not need access to production hosts to debug issues. For
example, a good workflow allows developers to spin up a cluster locally on
dummy data they control. However within production they would only have access
to logs. This way data exfiltration is prevented because direct access to data
is simply not allowed._

\----

I read that as saying "no, don't run random containers to attach to prod,
instead rely on orchestration to get you logs and instrumentation". Or is the
entirety of your argument "containers are bad because images are full of
vulns"?

~~~
verdverm
I'm not saying containers are bad, I use them everywhere. They require the
same audit and lockdown that the host system needs. If the container accesses
data, and the container has vulns, then we still have to deal with situation
1, malicious actors.

From the article:

> Another form of system hardening you can use is containers.

