2

My team needs to install and administer a very big application on Red Hat 5.7, and needs to be able to do so as root. During the project, the Unix support team (which is responsible for the OS support) grants us (the application support team) sudo all access so we can do so. However, our internal policy dictates that once the server has been operationalized (becomes officially supported by our Unix team and goes live), that nobody but them should have root access.

To be able to definitely support the application in question, my team would need to provide a complete list of commands and access requirements to the Unix team so they can grant us sudo access to all those commands individually. The vendor of the application does not support this type of restrictive administration and does not have a defined recipe to properly do this without issues. It will pretty much be trial and error.

That said, what would be the best method to list all the required commands we would need to run, and to list every directory/file access we will need?

The application being installed as root, all files under its installation directory are currently owned either by root or by the service user (user created for the application's service).

I have started by listing all files with perms u+x, and came up with a stunning count of 2801 files after a base, unmodified installation. That's excluding init scripts in /etc/init.d, and other system commands (such as chown, chmod, ps, kill etc...) that we may have to run as well.

To me, it sounds almost impossible (or at least extremely difficult) to do this without encountering problems later. I understand this is not an easy question and that there could be many ways to do this, but I would nevertheless like to hear the community's take on this.

Yanick Girouard
  • 2,295
  • 1
  • 17
  • 18

2 Answers2

1

First, I like your initial approach of finding all executable files. It seems that the vendor has a bad habit of marking everything executable, though. I really hope there are not 2,801 binaries in the product! You could probably pass all these files through file and see which are actually binaries, scripts, etc. That should narrow the scope.

Second, definitely include whatever is requried to stop and start the application. Sounds like the vendor installs an init script, so that's probably all you need. Also access to less any log files if they are stored in a system location such as /var/log and not readable by unprivileged users.

Finally, see if they can set up the sudo rules so as to allow your team to run particular commands as the service user. For example, you may want to run vim as this user to modify configuration files. If they want to be more restrictive take a look at the naming conventions of the configuration files. Perhaps a rule that allows vim *.conf (or a more complex glob or globs).

Another thought that comes to mind is having a clear escalation path in case of a future issue. Do you have someone you can page should you need something done in a pinch? Will they be monitoring the health of the system? Can they have your team notified in case of application failure?

Kyle Smith
  • 9,563
  • 1
  • 30
  • 32
  • The application is a server automation solution, which comes with a ton of cross-platform commands and libraries. Yes, it has this many libraries and other executables, scripts and such. It's that big. That said, I like your idea to use file to limit the scope, I'll try that, but I expect a lot of executables still... As for support and a contact to page, yes we'll have that, but it adds delays and will greatly affect our service level agreements if we have to go that route everytime we can't run a command. – Yanick Girouard Mar 20 '12 at 15:39
  • How would you chain `find` and `file` together to find all executables exactly? Did you have something specific in mind or you were just mentioning `file` as an fyi? – Yanick Girouard Mar 20 '12 at 20:48
  • 1
    I'd probably use a bash script with intermediate files to store the output of find, and use a `while read` loop on that file to get the output of `file` for each file in question. Then with that data (space delimited file of filename and output of `file`) I could decide which types of files are actually designed to be run (e.g. ELF binaries, Bourne Shell scripts, Python scripts) and which are improperly marked +x (e.g. ASCII Text files, Data files). – Kyle Smith Mar 20 '12 at 21:23
  • Thanks Kyle, I know where to go with this. Chances are though, that when the Unix team seems the insane amount of commands they'll have to add in `sudoers`, that they will end up just giving us sudo all anyway... – Yanick Girouard Mar 21 '12 at 02:47
0

Here are some points that can be considered useful to you (hopefully):

  1. A web interface will prevent the need to have ssh access and thus sudo privileges.
  2. Once the application is running properly, it should be the sysadmin team responsibility to make sure it is up and running not the developers'.
  3. You can request the permissions to modify the application configuration files and some data files if any. No need to modify every single file/folder of the application.
  4. If this is a testing server, more flexibility should be granted to the developers to be able to easily debug the application.
Khaled
  • 35,688
  • 8
  • 69
  • 98
  • Just to clarify, my team are not developers, we are the actual application support, and the only ones trained to administer the application. The Unix support team is only responsible for the OS itself, not 3rd party applications. Essentially, we are both the client and the application support. As for need to modify files, yes we do. The application is a very big enterprise solution that is constantly evolving. We've had to make a lot of modifications on the fly already, almost day to day, and having such a heavy access on demand process would kill us with paperwork due to the sheer size of it. – Yanick Girouard Mar 20 '12 at 15:42