03-13-2013 12:05 AM
I want to install sudo in HP UX server for 11iv1,11iv2,11iv3.
I want to know
1.for all favours,will the sudo version be same ?
2.Will the absolute path differs from each version like /usr/local/bin/sudo or /usr/bin/sudo
3.is there any security issue in installing sudo.
03-13-2013 05:48 AM
1.) Maybe, depending on where you get it.
- HP offers a version of sudo in the Internet Express kit, downloadable from software.hp.com. However, the Internet Express kit currently exists for 11iv2 and 11iv3 only. An old version of the Internet Express kit for 11iv1 can be found in most 11iv1 DVD media kits.
- sudo is available as a depot in HP-UX Porting Archive ( http://hpux.connect.org.uk/ ). It is usually newer than the version offered by HP, and the same version is available for 11iv1, 11iv2 and 11iv3. However, this version is not guaranteed by HP in any way.
2.) The Internet Express versions will install to /opt/iexpress/bin/sudo with a symlink as /usr/bin/sudo. The Porting Archive versions will install as /usr/local/bin/sudo.
3.) With the Porting Archive version, you're relying on security software compiled by volunteers on the Internet. You don't know how carefully they've checked that the source code is genuine and free of backdoors. With the HP-packaged version, you at least have someone to complain to.
With any version of sudo, you should understand what you're doing. Sudo is a powerful tool for granting access to users selectively: you should read its man pages and understand how to configure it to fit your requirements. If you just use the "cookbook"instructions on the Internet to set up the minimal configuration (e.g. allow all the users to run "sudo su -"), then you're missing the point of sudo and not making the system any more secure at all. If you are not careful in setting up the access rules in the sudoers files, you may accidentally the users more extensive admin access than you intended, making the system less secure than without sudo.
In most cases, you must find the correct balance between security and usability: if the users will feel that sudo is just an inconvenient extra step when it is introduced, they will look for ways to work around it. Instead, you should look for ways to make the new way with sudo simpler and/or easier than the old way to do things without sudo.
For example: if a non-admin user needs to access an application user account to perform a particular task using a complicated command line, allowing the user to run "sudo su - appuser" is not the optimal solution: it is just an extra step. Instead, you might write a script that includes the necessary sudo command, takes care of moving to the correct directory and simplifies the required command line, and place it to a directory that is in $PATH. Now the user will be able to perform the task while being in any directory, with a simpler command line. From the user perspective, if the user is authorized to perform the task, the script "just does it" with minimal complications; if an unauthorized user attempts the same command, he will only receive sudo's "you are not authorized to run this command" message.