1

I have a Debian server that some people should be able to ssh to. [Edit]: Meaning use the software on that server. Execute whatever user-targeted programs installed on it. E.g. run elinks, mc, gcc or firefox per x-forwarding. Important I am not asking for detailed permissions for the examples I listed, I am just clarifying what I mean by user.[/Edit]

Regardless if I trust them or not, I want the server to have clean and secure permissions. (I have a feeling that by default multi-user security is beig compromised for single-user convenience. Evidenced by useless default read permissions on /home, for instance...). Especially regarding /etc which has rwxr-xr-x by default. Anyone can read the directory, and I find that troubling, but maybe unbeknownst to me, that is necessary.

Can someone, maybe some bearded old Unix admin, tell me how to set the permissions on a multi-user server? Especially for:

  • /var
  • /etc
  • /home
  • /opt
AndreasT
  • 837
  • 2
  • 10
  • 16
  • Leave everything on default permissions. – Ipor Sircer Sep 19 '16 at 08:35
  • Could you elaborate a bit? Why the strange read permissions on directories that don't need them? – AndreasT Sep 19 '16 at 08:43
  • erm... var:1234 because "Five", etc 0666 because "Evil", home: 0070 because "James...", opt: 1313 because "Donald" would be a funny but complete answer. How is the question too broad? – AndreasT Sep 19 '16 at 13:24
  • 1
    It's too broad because a full answer to that would be really long and also dependent on what the system in question is supposed to do. There is no "one size fits it all" to this. – Sven Sep 19 '16 at 13:26

1 Answers1

2

Leave it as it is if you don't fully understand what you are doing.

As an example, everyone needs to read in /etc for many things.

  • /etc/passwd needs to be read to map numerical user ids to user names
  • default configs must be read for shells, SSH and many other things (e.g. /etc/bashrc, /etc/profile, /etc/ssh/ssh_config)

You will find that the files that are critical (e.g. /etc/shadow) are readable by root only.

I believe you are going about this the wrong way anyway. Don't think about what users need to see and instead decide what they really shouldn't see and make these files inaccessible. This is usually a surprisingly short list and also in most cases already done by the developers or package maintainers.

What are these things? On most systems:

  • shadow and gshadow.
  • SSH and SSL private keys
  • Files including passwords if I can't avoid those.
  • Firewall rules

Everything else is really not critical for a user to read and, since I never touch most of the files in /etc to begin with, they can see those files by installing the same OS and packages to a private system anyway.

Sven
  • 98,649
  • 14
  • 180
  • 226
  • With Wheezy, i usually go with "jailkit" and creare multi user without even touching them self, each witch they own file. More fancy setup would be LXC virtualization to setup a specific environment for each user – x86fantini Sep 19 '16 at 11:20
  • @Sven: Are you sure you do not confuse directory read permissions with file read permissions? All your examples only need execute on /etc. – AndreasT Sep 19 '16 at 13:11
  • Yes, I am sure. Example: It's legitimate for users to want to `less` some files to see what's in there, e.g. to optimize their own dotfiles. In that case it helps if you can `ls` into `/etc` to see what is really present. Also, sometimes it's not clear where certain files are. I've seen `/etc/ssh_config`,`/etc/sshd/ssh_config` and `/etc/ssh/ssh_config`... – Sven Sep 19 '16 at 13:22
  • The question is about users not administrators, which is clearly stated. I know we all confuse this since linux people usually are their own sysadmins, and since ubuntu we are not used to be able to access parts of the system (compared with debians sbin policy), The examples you provide are noithing a user should ever read. – AndreasT Sep 19 '16 at 13:42
  • @AndreasT: Wrong. As a user, I have a legitimate interest to understand how my shell or my ssh client are configured. Sure, you *can* restrict that but then prepare to have grumpy users. So, in some cases it might be OK to restrict that, in others it's not (thus: too broad). Again, if you don't fully understand what your doing, leave stuff alone. – Sven Sep 19 '16 at 13:45
  • Ok, The question is on hold because of broadness. Can you please give me a constructive hint, howto reword the question to make it fit the criteria in your opinion? – AndreasT Sep 19 '16 at 14:38
  • @AndreasT: No, I really can't because I can't see how this question can be reasonably scoped. See my edit though for a constructive hint. – Sven Sep 19 '16 at 16:13