Hacker News Reader

Hacker News

Comment by SoftTalker | Hacker News Reader

Parent Full thread

SoftTalker

bash actually has a "restricted" mode which is sort of like that. In restricted mode, the following are disallowed:

- Changing directories with cd.

- Setting or unsetting the values of SHELL, PATH, HISTFILE, ENV, or BASH_ENV.

- Specifying command names containing /.

- Importing function definitions from the shell environment at startup.

- Parsing the values of BASHOPTS and SHELLOPTS from the shell environment at startup.

... some other things mainly preventing you from escaping or disabling the restricted mode.

View on HN

Does that work? I've never seen it used. It seems easy to escape.

The docs seem to suggest using alternate approaches.

> Modern systems provide more secure ways to implement a restricted environment, such as jails, zones, or containers.

https://www.gnu.org/software/bash/manual/html_node/The-Restr...

>> bash actually has a "restricted" mode ...

> Does that work? I've never seen it used. It seems easy to escape.

Yes, it does work for its intended purpose. It has often been used in combination with chroot[0] as well.

> The docs seem to suggest using alternate approaches.

>> Modern systems provide more secure ways to implement a restricted environment, such as jails, zones, or containers.

These approaches are not mutually exclusive with restricted shell use. For example, one could use FreeBSD jails to secure Apache httpd and/or Nginx and still employ a restricted shell to evaluate requests.

0 - https://man.freebsd.org/cgi/man.cgi?query=chroot&apropos=0&s...

I'm seeing a ton of restricted mode escapes documented online, like https://0xffsec.com/handbook/shells/restricted-shells/ so I'm not so sure. When basic utilities like less, man, and awk can run subshells it's quite a mess.

Bash restricted mode needing a chroot may suggest that Claude also needs a chroot (or restricted file permissions, jail, etc).

> Bash restricted mode needing a chroot may suggest that Claude also needs a chroot (or restricted file permissions, jail, etc).

I believe running coding agents within a jail/container is a "best practice" to limit their blast radius. At least, this is what people I respect have conveyed to me.

I don't think I've ever seen it used. I think the idea was back in the day when you wanted to let a user have a shell login (because that's the only way you could use a shared computer) but wanted to confine them to a specific directory and prevent them running anything that wasn't in the pre-defined PATH that you set for them.

You could also produce special purpose applications this way, say to provide access to the online library catalog, or a run a gopher client for use in a public terminal lab. Telnetting to a unix account running some sort of restricted shell was how these often worked.

A sibling comment I can't reply to asks if you can do with with unix permissions.

These were really intended for anonymous guest access, or at least often used for this purpose. You couldn't do the same things with the file permissions systems at the time.

Back in the day we'd use chroot to achieve something similar

https://linux.die.net/man/1/chroot

Yes, in reality you might use chroot, limited filesystem permissions, and a restricted shell as a belt-and-suspenders approach.

Can't you do that with regular Unix permissions?

Reply on news.ycombinator.com