15

I have an application which runs as a daemon and is controlled by a script in /etc/init.d
Sometimes we need to change some parameters of startup/control of these scripts and then restart the daemon. These scripts only have write permission for the root user, so when editing these scripts I need root privileges.

What I was thinking is that should I make a non-root user the owner of those scripts. This way only root and a special user can edit these scripts.

Is it acceptable to keep some non-root owned files under /etc/init.d directories?
Or it is absurd, disturbing the natural order of the system?

Improve this question
1

2 Answers 2

Reset to default
17

What immediately comes to mind is an underprivileged user being able to run things on boot as root, which is desirable to crackers that:

  • Want to escalate privileges of other accounts
  • Want to use your server to host a rogue service
  • Want to start IRC/Spam bots if the server reboots
  • Want to ping a mother ship to say "I'm up again" and perhaps download a new payload
  • Want to clean up their tracks
  • ... other badness.

This is possible if your underprivileged user is somehow compromised, perhaps through another service (http/etc). Most attackers will quickly run an ls or find on/of everything in /etc just to see if such possibilities exist, there's shells written in various languages they use that makes this simple.

If you manage the server remotely, mostly via SSH, there's a very good chance that you won't even see this unless you inspect the init script, because you won't see the output at boot (though, you should be using something that checks hashes of those scripts against known hashes to see if something changed, or version control software, etc)

You definitely don't want that to happen, root really needs to own that init script. You could add the development user to the list of sudoers so that it's convenient enough to update the script, but I'd advise not allowing underprivileged write access to anything in init.d

Improve this answer
1
  • 5
    tl;dr: If you do this, the non-root user is as good as root on the next boot. You're begging to be pwned.
    – Warren Young
    Jan 30, 2014 at 10:38
9

In addition to the very good points made by Tim Post, I'd add that for a setup where multiple people need to be able to push changes onto a server, you should consider using some kind of configuration management system.

If you e.g. use puppet, or chef, or cfengine, you can have the relevant users edit the files locally and then push the changes out with the config management. Exactly how to set this up will of course vary depending on which system you're using, but properly set-up it will include versioning software making it easy to revert to an earlier version of a config file when (note: when, not if!) someone's made a mistake. It will also make it easier for you to copy configuration to a separate test system etc.

Improve this answer
4
  • Keeping both your scripts and even your configuration data files versioned in a configuration/version management system is an excellent idea, even without considering whether a system could be compromised.
    – ChuckCottrill
    Jan 30, 2014 at 19:51
  • Indeed - I've used it for fixing mistakes about a couple of magnitudes more often that I've used it for fixing a compromised system.
    – Jenny D
    Jan 31, 2014 at 6:56
  • Thank you very much . Because here mostly a dedicated user uses this application so sudo is quitely working and this what I was doing from long time. BUT I am REALLY very much interested version management system for the configs . Dear Jenny can you provide me any refrence for doing so OR ANY EXAMPLE!! :).
    – Akaks
    Jan 31, 2014 at 7:10
  • 1
    If you don't want to go with the full puppet/chef/cfengine etc route, I would personally use www.perforce.com. We used that for ~100 servers in the time before puppet existed and their eval license is enough for one server. The main advantage is that you can checkout VC'd files to any place in the file system instead of being limited to one subpath. Other options are joeyh.name/code/etckeeper , or using any VC combined with scripts to move files to the proper directory.
    – Jenny D
    Feb 1, 2014 at 9:11

You must log in to answer this question.

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