How to create a confined user in Ubuntu?
Posted by BagCompetitive357@reddit | sysadmin | View on Reddit | 18 comments
I have a question that looks like basic to system administration, but surprisingly I cannot find information about that.
I have a multi user system. I want to make sure that a particular user has access only to a set of resources like a set of applications.
Traditional Unix DAC permissions don’t seem to provide a simple solution to role-based access control. It seems MAC using SeLinux or AppArmor is required.
RHEL/Fedora have SeLinux with targeted policy which comes with labels for users, like, guest_u label for the context of a predefined confined user. I can create a new user and label it with guest_u. This way the user will be confined to capabilities defined by guest_u. It’s hard to cherry pick and compile new modules (guest is more like a kiosk), but at least there is something.
But I have Debian/Ubuntu. To my surprise, I found it difficult to create a user that is confined in Ubuntu. I can remove the user from the sudo group and prevent the user from running certain commands like su. That’s all.
I want to define a user that has access to certain folders and can run certain applications (like a browser, vscode, editors, other basic utilities) and nothing more. How could this be done?
The closest that I found was installing and configuring an obscure module called AppArmor PAM module. I might be wrong but there might be just one example in the internet on this module and almost none in Reddit. It’s not well documented.
There ought to be an easy way to confine a user in Ubuntu.
pdp10@reddit
The traditional way from way back, was to set the user's shell to a confined application, from which the user couldn't escape. The catch was that a lot of applications would offer a way to escape, if you weren't super careful.
How secure do you need/want to be? What do you specifically not want them to do? What are your next-beat alternatives? Does this need to be maintained by a semi-skilled staff in the future?
GUI apps on console? How about an air gap?
BagCompetitive357@reddit (OP)
I found that there are countless ways to escape restrictions: PAM, PolKit, graphical apps, and so on. I’m surprised the situation is like this. It’s a mess. Is Android or iOS sandboxing just as bad?
For example, even if you remove a user from the sudo group and disable su, the user can still install or uninstall apps using the GNOME Software Manager. A prompt appears asking for the admin password, essentially allowing the user to attempt a sudo operation. Why is that? Any “sudo command” should simply result in permission denied.
For network segmentation, there are tools: you can put workstations in a VLAN and add firewall rules that only allow connections to the Internet, blocking any access within your internal infrastructure. The difficulty is confining the user account.
As for the level of security required, it probably doesn’t need to be very high. I imagine some users might be tempted to steal IP, licensed software, etc., as often happens in companies. It’s mostly for myself, I just got interested to do this properly (configure a confined namespace with no way to change hat to another). White-listing is better than black listing.
Yes, users have access to some graphical applications as well as command-line utilities. They also need Internet access, which means they could download malware and see what can be done with it. There’s no TLS termination at the firewall to inspect traffic.This should be a common setup.
n3t_admin@reddit
Certain folders is going to be harder I guess, but you should be able to do this with standard Linux permissions.
For programs, my idea would be to use a custom $PATH variable, and make the profile config read-only for the user, so that they can't escape it. Then symlink the binaries into that directory from $PATH and the user will only be able to execute those binaries.
It should work.
Hotshot55@reddit
That's pretty trivial to get around with a
export PATH=$PATH:/my/new/dirn3t_admin@reddit
I just created an alias export=no and it just gives you "command not found". So I'd say it's not so trivial ;)
Hotshot55@reddit
Ok, adding a single \ infront of the command will ignore your alias, so it's back to being trivial.
n3t_admin@reddit
yeah okay, I'm a dummy. You need to set the login shell to rbash, so that env's can't be modified. That's the "official" way.
michaelpaoli@reddit
You can lock 'em into a properly constructed and confined chroot and/or use SELinux, or maybe AppArmor. But if you're trying to let 'em have X or Wayland or any GUI app stuff, they'll likely have lots of ways to break out. Possibly similar if you give 'em network. So, browser, how 'bout only give 'em lynx or w3m, and no Internet or networking?
Anyway, can give a user quite locked down access.
E.g. try:
$ ssh -T myip@balug.org
BagCompetitive357@reddit (OP)
With X, I agree. But I thought Wayland addressed those issues and has some level of sandboxing. In other words, access to Wayland socket shouldn’t let them out of their namespace.
For networking I’m not sure. Guest_u context in SeLinux provides access to browser and internet in a potentially hostile environment (like a kiosk in an Internet cafe).
michaelpaoli@reddit
Well, Wayland, network ... even with SELinux I wouldn't trust 'em that much. May quite depend what the threat model is (who's using it, and what they can get to on The Internet), and what you're trying to protect. E.g. do you care if they do arbitrary network things and/or do arbitrary read/write to display / keyboard / pointing device / camera / microphone? Or you just concerned about protecting the integrity of the OS itself, and don't care if local audio/video is passed live to some crackers in some random country?
nukacola2022@reddit
I think a KASM container is your best bet for ease of use and isolation (make sure you don’t give them a container that is privileged and or with root). Another option could be bubblewrap (basically an easier (imo) way of doing chroot) and isolating the binaries and utilities into their “root.”
BagCompetitive357@reddit (OP)
Yeah, I had looked into both.
Bwrap is pretty secure to wrap around single binary. But you will find few bwrap scripts, and doesn’t scale for an entire account. For apps, ultimately it’s better to use user-space flatpaks installed in users account that’s uses the same tool plus some more sandboxing features of kernel. I’m thinking making flatpaks for my apps.
KASM is a much better solution. The institution won’t approve use of third party images (like downloading chrome browser or Linux from a rather unknown startup!). I have seen tutorials, but haven’t installed it. Custom images seem supported, should look into it.
MrAlfabet@reddit
You're looking for visudo. You can specify which binaries users are able to run without sudo.
BagCompetitive357@reddit (OP)
Wrong ! Visudo of course is well known but it’s a different thing: some executables need sudo and visudo provides exceptions.
In this case, I want the opposite. In fact, I already removed the user from sudo group so that they can’t run sudo applications. Normally the user can run all non-sudo applications. I want to restrict those. The apps that are whitelisted do not require sudo.
gihutgishuiruv@reddit
Is the user physically accessing the system, or are they remote?
Is this a multi-user system? Or is just the locked-down user that’ll be operating it?
BagCompetitive357@reddit (OP)
These are workstation desktops. No RDP, but users have ssh access (to access their data and check on running processes).
MrAlfabet@reddit
restricted bash then?
bashchsh -s /bin/rbash <username>sudo mkdir /home/<username>/bin sudo chmod 755 /home/<username>/binecho "PATH=$HOME/bin" >> /home/<username>/.bashrc echo "export PATH >> /home/<username>/.bashrcsudo ln -s /bin/<command> /home/<username>/bin/chattr +i /home/<username>/.bashrcBagCompetitive357@reddit (OP)
Yeah, restricted bash, coupled with symlinks to the required binaries in a particular path (as mentioned by the other commenter), is something people do.
I’m sure it will confine a causal user, not sure if it’s bullet proof for a sophisticated expert.