1

I was wondering today if there was a way to enforce a non root user to have a specific authorized_keys file (among other sensible files). I came up with this solution.

  • Disable StrictModes in sshd_config (got to manoeuvre with file ownership and stuff, and sshd with StrictModes active is very picky)
  • Prevent the user from deleting files not owned by himself in his home directory with the sticky bit:

    • chown root:user /home/user
    • chmod 1770 /home/user
  • Every file and directory that should not be modified/removed should go through this:

    • chown root:user file_or_folder
    • chmod 0640 file_or_folder
    • chmod g+x folder

So far this approach seems to work. The user cannot modify/delete the files, and there's no risk that the user leaves his own home folder readable/writable (this seems to be the reason behind StrictModes) because he does not own his home directory.

The question is: am I missing something? Can this be circumvented? Are there drawbacks?

0

2 Answers 2

0

Looks fine but in linux probably there is always some way to get around it, because once you have an account, escalating your priv. is far easier than breaking in, if you do not trust your users. If you are really concerned, I would suggest some sort of restricted or limited shell. These are not hacking-proof either but tend to help with most cases.

You can make it a little harder for the user to chattr +i file to make it immutable.

0

I would leave StrictModes enabled. It is intended to make it difficult for someone else to replace a users' AuthorizedKeys file. You may have secured this user, but all the other users are vulnerable.

There are a variety of tools that can be uses to reestablish a sane configuration if it gets broken. I have been using cfengine. puppet is a popular alternative. Even if the user changes their settings, the tool will reset the configuration back to a sane state. If desired it can alert that the change was required.

From your requirements, it would appear you are securing an account for a service. Normally, these accounts wouldn't have a password and not a normal user's account. This kind of requirement for a normal user's account would raise my security hackles. As a user, I wouldn't accept this kind of restriction on my account. As an adminstrator, I would be concerned that the account is being used for purposes with two different security profiles.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .