I'm trying to prevent a separate user I've created from being able to access any program other than the one it's designed to run. Is there a way to prevent read access to something like /bin/bash and other programs?

I've also been trying to use PAM to restrict this user to a single process and single login.


@username hard maxlogins 1
@username hard nproc 1

I can't get this to enforce though. I can still log into username and run /bin/bash and grep and top etc. I have two shells open and I can run top/grep in both, and it shows multiple processes running (process I want running, and the top/bash/grep processes I'm running that I want to be denied)

The easiest way that *MIGHT* do what you're after, is just to set that users login shell to be that one program. Put your program name into /etc/shells, and usermod that user's shell.

That is only going to be as effective as the program itself...since, if it's designed to offer a shell as PART of itself will, or allow itself to be paused/backgrounded with CTRL-Z (thus allowing shell), there still may be a way to do it. Easy to try, though.

The login right now is /bin/false, but I want the restriction to apply to the entire user account. Basically if the program is compromised I don't it to be able to do *anything*. I can restrict it with LSM like Apparmor, but I want something that's a bit more cross-distro, like DAC.

At the moment it has a lot of read access, and it can execute files like top and grep etc, which isn't such a huge issue, but I'd prefer that it be completely unable to do so.

Perhaps a chroot jail would meet your requirements.

Don't know if this helps, and be warned, I've been known to post newbie nonsense, but here's my idea:

If a remote user executes a command by ssh with public key authentication, you can use the command="string" option in the authorized_keys file to restrict or force the command. I have used that (in the case of remote login, not local) to run a command filtering script (command="my_command_filter"); this allows a few selected commands to be executed, and even the arguments can be filtered. If the command and its arguments never change, you may specify the exact command (command="my_command").

If your user is a real person logging in locally and interactively, I don't know how this will work. If it is a process created in the user's name by a script, you should be able to run it via ssh to the local machine. I haven't tried this, but I don't see why it wouldn't work. You would have to restrict the user to logging in only via ssh, not interactively or any other way such as su.

I attempted to read the manual and see whether bash can be invoked with such a command filter. I saw something about restricted shell, but that's not quite what I had in mind, so I'm still not sure if bash itself can be set up with arbitrary restrictions for one user.

If you're really paranoid, combine TB0ne & allend's suggestions; use the app program as the login shell and create a chroot jail for it to run in.

It is chrooted at the moment. I just can't seem to get TPM working.

@Beryllos,

That won't quite work for this.

I'd recommend a chroot jailshell to prevent directory transversal and absolute path searching, and a nullified path that prevents searching for binaries that don't exist outside the user's home directory.

If you can, do what TB0ne said and make the program the user's shell. Even if they manage to escape the program via various signals, they're dropped in an environment that does nothing. They would have to attack the chroot shell to gain extra access, putting them in a weaker position. It also prevents remote command execution via SSH.

The process is chrooted within it, but I'm trying to restrict the user itself.

The program uses /bin/false as a shell.

What is this?

Setting their path to only search the local directory. Or no path at all. So if they attempt to execute `ls`, they get a no such program. *nix will always first check the local directory for the path to an executable, then fall back to the path variable defined.

It stops casual/automated attacks, which will be your biggest concern.

But if your $PATH and $SHELL envs are properly hardened, someone can't set them to their own path or shell and escape the jailshell.

See this for some more info: http://pen-testing.sans.org/blog/201...d-linux-shells

Could you be specific what application this is about?


Security is a trade-off and MAC works on top of DAC. Since you say your app is jailed what exactly do you provide inside your jail in terms of binaries, mounted partitions, devices and VFses?

Thanks, I'm looking to do more than stop automated attacks, but I'll do it anyways - may as well pile it on.

@unSpawn,

It's not the app I want restricted though, it's the user. the app (dnscrypt) requires virtually no resources, and chroots to an empty directory. That's why I'm looking at DAC.

So what shell does the user have? Do any /etc/security/{access,chroot,limits}.conf restrictions apply? What exactly do you provide inside your jail in terms of binaries, mounted partitions, devices and VFses? (I'm talking factual details, not a fuzzy human description like "virtually no resources".)