Create restricted user account

[Sinopa]

Could someone please explain to me how I can create a user account in RP with restricted access?
The user should only be allowed to add/remove files/directories in their account, and not be allowed to enter anything except their home account.

[Joe Schmoe]

GUI or shell-only?

You can get close to what you want using "rsh", at the shell level.

But I have no ideas about how to do this sort of thing in a GUI environment.

[Sinopa]

I ssh into my RP, and I don't use any GUI. So it have to be done from terminal. I'm a noob, so if you could explain in a way that even a noob could understand, that would be great

[Joe Schmoe]

I ssh into my RP, and I don't use any GUI. So it have to be done from terminal.

OK. Basically, this should get you close:

1) use "adduser" to create a new user -

Code: Select all

man adduser

for the details.

2) use chsh to change the newly created user's shell to "/bin/rbash"

Then test out the new user and figure out what you can (and more importantly, can't) do.

P.S. "man adduser" says that /bin/rbash shouldn't be in /etc/shells, but (at least on my Pi), it is.

[Sinopa]

That was WAY to complex for me. When there is to much text/info I get confused. I think I'll drop that little project. But thanks for the help anyways, Joe Schmoe

[RaTTuS]

ssh into RPI
sudo adduser newbie
give password
exit

ssh newbie@RPI


you have now got a restricted account

[Joe Schmoe]

ssh into RPI
sudo adduser newbie
give password
exit

ssh newbie@RPI


you have now got a restricted account

In what sense is it "restricted"?

[Sinopa]

I have no idea. Tried it, and it was everything but restricted.

[jojopi]

P.S. "man adduser" says that /bin/rbash shouldn't be in /etc/shells, but (at least on my Pi), it is.

I do not see that in my man page, but it is correct. With rbash in /etc/shells, nothing prevents the user from "chsh -s /bin/bash" again.

Restricted shells are a waste of time anyway though. First thing the user is going to try is:

Code: Select all

perl -e'exec bash'

To prevent every escape of this type you would need to uninstall all useful packages, not only making the system restricted for everyone, but very likely making it unbootable.

Really, restricted users would have to be given a different PATH, with only vetted binaries in it. If you were going to build such a directory, you would be much better to chroot into it instead of rely on a restricted shell.

[Joe Schmoe]

You are completely wrong about this. It can be done, and it has been done. Really, saying it can't be done is just "hackerese" for "I don't like it; it is morally wrong to try to restrict what people do.". Don't bother denying it; I've seen it too many times.

And trust me, I know all the tricks and the fixes to those tricks.

To do it, you have to start with the (short) list of things that you want the user to be able to do. Not, the other way around - thinking of the list of things you don't want them to do. In any case, you certainly don't have to uninstall anything, nor do you have to mess around with "chroot".

Once you do that (come up with the short list), the follow-through is obvious; I won't bore you with the details.

But, I think we both agree that doing it is beyond the OP's abilities and plans.

And, of course, there's always the question of the actual realities of the instant situation; i.e., how determined is the user and how important is it that the solution be airtight.

[jojopi]

You are completely wrong about this. It can be done, and it has been done.

Evidently I was not clear. I did not say it could not be done.

I demonstrated that it does not work out of the box, and that it is impractical even to create a minimal install where it works out of the box. I concluded that to make it work you have to provide a non-standard PATH with only vetted binaries. You appear to agree.

And for the record, I am not morally opposed to restricting access. But I do think the traditional restricted shell is a time-consuming and error-prone way to configure that. At the low-functioning end of the scale I would prefer a custom "shell", and at the high-functioning end a chroot or UML or VM. You could easily argue that those are time-consuming to configure as well.

[JeremyF]

In my opinion, based on having tried many solutions in the past like restricted shells, chroot jails, and the like, I've found it all to be too much of hassle yielding results that aren't even close to perfect. I've found that keeping a restricted user out of the sudoers file (i.e. no way to become admin unless they know another user's password) is sufficient and requires zero setup. To some this may seem fairly insecure but recall that not being in the admin group is the standard for Windows security and no one ever complains too much about that. If you want you can always block specific programs.

[RaTTuS]

I have no idea. Tried it, and it was everything but restricted.

you cannot sudo
edit other things
how restricted do you want it to be

[Joe Schmoe]

Unix, by its nature, is a pretty open system. Unlike (classical) IBM OSes, its motto is "that which is not specifically prohibited is permitted" (rather than the converse).

So, a non-root user can often do a lot of damage (even without any special privs) ...

[JeremyF]

Unix, by its nature, is a pretty open system. Unlike (classical) IBM OSes, its motto is "that which is not specifically prohibited is permitted" (rather than the converse).

So, a non-root user can often do a lot of damage (even without any special privs) ...

I disagree. They can run a lot of programs that would make a Windows admin freak out but in the end most everything important is owned by root or at the very least, another user.

[sprinkmeier]

So, a non-root user can often do a lot of damage (even without any special privs) ...

I don't think any current consumer OS is much different in this respect.

'user friendliness' tends to trump security in the default setup.

A non-root user on a Linux box can WRITE to their home directory and /tmp, and READ pretty much anything (some sensitive files (e.g. /etc/shadow), directories (e.g. /root) and some parts of the virtual filesystems (/proc, /sys) are exceptions).

If that can cause 'a lot of damage' on your system then there are ways to limit this.

I'm not too familiar with Windows or OS-X but I believe they're pretty much the same.