3

This is a followup on my question here.

I am setting up the first webserver and am fumbling with what user accounts to create and permissions to provide for better security. Below is what I have.

For 2 developers, I have 2 accounts (and they are added to the supplementary group devs) and only they are allowed to ssh to the server. For the web application (Django based), I have created 1 normal user, app (haven't configured it as --system user and belongs to group app) with shell access. The 2 developers, after ssh to the server, will su to app for any updates and starting/stopping the application. User app is not allowed to perform su (blocked by not adding to the group setting in /etc/pam.d/su using pam_wheel.so). I also have a 3rd account with no su capabilities for backup related tasks where a cron job will ssh and fetch log files, status, etc.

Let me know if security aspects need to be made better. (PS: I am a novice here)

Improve this question
3
  • Instead of the developers having to su app maybe you could use either file system ACLs to give appropriate default access rights to the user app. Or chown all appropriate files from the developers to app either in a cron job or on demand (monitoring the files with a FAM daemon). Commented Oct 6, 2013 at 21:03
  • @peterph Yes, doing su app will gradually turn out to be a pain in the process. But I guess I don't know how to do what you said. May be an example will help? Commented Oct 6, 2013 at 21:39
  • see @dannbysauer's answer - it's exactly what I have had in mind. :) Commented Oct 7, 2013 at 8:39

1 Answer 1

Reset to default
2

su requires sharing a password. I prefer sudo. So, developers would run either sudo -u app command to run command as app, or run sudo -u app -i to start an interactive shell as app. Possibly sudo -u app -i /bin/bash if you've set app's shell to something like /bin/false or /bin/true.

If they don't need a full shell as the app, but rather only need to restart the app, you can limit the commands they can run as app. Use a default ACL on the directories they need to access which grants access to the devs and to the app so you don't have filesystem permission issues. The principle of least privilege is what you need to follow, IMHO. If they don't need to do it, don't give them access to do it.

Typically I prefer to use keys only for ssh. If you can do that, disable passwords for the devs, and set the sudo rules to not require a password. Then there's no passwords needed for anyone, and thus no password to disclose / lose / reset.

Reading assignment for this evening, because it's a bit much for this post: "how do filesystem ACLs work" and "how do I configure sudo". Perhaps followed by managing ssh keys.

Improve this answer
8
  • Well, I know sudoers.d/* format and sshd_config setup. Not conversant with fs ACLs. Are you harping on setfacl/getfacl? Commented Oct 6, 2013 at 22:08
  • 'you can limit the commands they can run as app' -- yes, I am having small bash scripts that for eg control the app via supervisorctl and currently running only them from app user using sudo configuration and without password. Commented Oct 6, 2013 at 22:12
  • Yes, I have blocked password for 1 user of the dev group. But enabled password access for the other -- just in case if my work machine crashes or backups die. However, I am planning to setup fail2ban, so hoping password access for the single user shouldnot pose any threat. BTW, for both users, I have passphrase -- don't feel too comfortable without it. Commented Oct 6, 2013 at 22:16
  • 1
    Here's a good starting point for ACLs: lithostech.com/2009/02/… Commented Oct 8, 2013 at 19:16
  • 1
    This is the ACL reference I typically share: users.suse.com/~agruen/acl/linux-acls/online It tells you all you probably ever wanted to know. Commented Oct 8, 2013 at 20:48

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.