I'm currently developing an application which needs root privileges for several operations (e.g. deleting system log files, etc.). One solution would be to implement a privileged helper tool which will be launched automatically by launchd. This way the user has to type in an administrator password every time such operation shall be executed (or every time the helper needs to be installed).
Now I wonder if it is possible to create an installer package which will install the application with root privileges so the user types in the administrator credentials just once (during the installation process) and every time the application gets started it is being launched with root permissions (without prompting for admin credentials).
Is there any way to achieve this?
The usual way to do this on Unix systems is to use setuid. Basically, you change the owner of your program to be root, and set the "set user or group ID on execution" bit (s):
$ chown root:root myprogram
$ chmod u+s myprogram
Any time a user then executes your program, it will run as root.
Note, though, that there are very good reasons for prompting for admin credentials.
Using this mechanism (or doing what you're trying to do, in general), can very easily lead to very dangerous security holes like privilege escalation. Any executable you use setuid on should be thoroughly audited by somone familiar with the process, otherwise attackers will root all machines your program is installed on.
Related
Question is about configuration of RHEL Operating System, or adding a custom script, I suppose.
I want to allow user1 to launch my program that reads a settings file owned by another user.
The final scope is:
to avoid user1 to be able to read the settings file.
to allow user1 to launch my program executable.
I supposed that my program and my settings file could be owned by root, giving user1 the right to execute the program. But If I do this, will the program be able to read settings file owned by root?
Is it there a solution to this problem, without customization of my program executable?
Edit:
The scope is to protect settings file content, but allow the user to use the application. Another way to solve the same problem with different question is:
Suppose that I give root privileges to exe and settings file, and then start the exe automatically during boot. User 1 will not be able to read settings file (this is what I want). Suppose that the exe is a terminal application that prints standard output and expects commands as standard input. Is it there a way, for user1, to read standard output and write standard input to the exe previously launched by root?
An attempt of an answer. Imagine /home/user/program is the program that should be run by user1, and /home/user/private-config-file the file that the program should be able to read (on behalf of user1) but not directly readable by user1.
In these configuration, I think the following should work:
create a custom group private-group (as root):
~ addgroup private-group
make the configuration file belong to private-group and group-readable (probably as root, unless your normal user is set to belong to the group too):
~ chown :private-group /home/user/private-config-file
~ chmod g+r /home/user/private-config-file
make the executable belong to the group and setgid (probably by root as well):
~ chown :private-group /home/user/program
~ chmod g+s /home/user/program
The program should not be in a scripted language, since setuid/setgid do not work in this case.
Using this, the program, when running, will have an effective group ID private-group, which should be enough to let it read the configuration file.
As far as I know, this should get you going, but you need to keep in mind that:
if there is any way for user1 to use the program to read arbitrary files, then your configuration file could be opened;
the program might re-write its configuration file, including the private bits, in a specific location, in a way that would be readable by user1;
any user that can execute /home/user/program will be able to use the configuration file (even if not read it).
IMPORTANT setuid/setgid processes are much harder to write and use in a secure way than you would believe...
I should again emphasize that if you have significant security implications of leaking the contents of the configuration file, you really should think and tread very carefully.
After successfully mounting the directory (ZFS remote storage) from one of the server, I'm getting an "Operation not permitted" error when I try changing the ownership of the directory. I'm using the following command:
To mount the remote directory:
mount -t nfs 10.1.32.33:/dir/temp/tools /home/materials
After mounting the directory, the contents are belongs to nobody:nobody
I want to change ownership so I can run the installer inside the directory.
I'm using the command below to change ownership but it's not working:
chown -R otm:otm materials/
I can always upload the file to the server without using the ZFS storage, however I want to start making a central installer repository so I don't need to upload the files/installers for future server install. I appreciate your help guys.
NFS servers by default do not allow root access to files - root is normally mapped to "nobody".
See "root squash":
Root squash[2][3] is a reduction of the access rights for the remote
superuser (root) when using identity authentication (local user is the
same as remote user). It is primarily a feature of NFS but may be
available on other systems as well.
This problem arises when a remote file system is shared by multiple
users. These users belong to one or multiple groups. In Unix, every
file and folder normally has separate permissions (read, write,
execute) for the owner (normally the creator of the file), for the
group to which the owner belongs, and for the "world" (all other
users). This allows restriction of read and write access only to the
authorized users while in general the NFS server must also be
protected by firewall.
A superuser has more rights than an ordinary user, being able to
change the file ownership, set arbitrary permissions, and access all
protected content. Even users that do need to have root access to
individual workstations may not be authorized for the similar actions
on a shared file system. Root squash reduces rights of the remote
root, making one no longer superuser. On UNIX like systems, root
squash option can be turned on and off in /etc/exports file on a
server side.
After implementing the root squash, the authorized superuser performs
restricted actions after logging into an NFS server directly and not
just by mounting the exported NFS folder.
In general, you DO NOT want to disable root squash unless you REALLY know what you're doing as there are serious security issues you can create if you do that. And since you didn't even know it exists...
(And that mention of /etc/exports is an extremely limited statement that is wrong on many systems - like Solaris.)
Currently I'm developing a control website for my home server. The server has LDAP setup for Mac's to login. The home directories are also on the server. I want to create a backup tool for my family, so they can backup while I'm off. I don't want to do this scheduled (at least not allways, since they must be able to start a backup right away).
I got stuck when I was trying to find a way to run the rsync commands as a privileged user.
I've got some ideas on this but I would like to hear the cons and pros of the options.
Create simple deamon that runs as root and backup's folder -arg1 to -arg2 minding the old backup in -arg3.
Run rsync as the logged in user by remembering the users pass at login at the control panel. (Problem: running ps will reveal password).
Create special rsync user (Problem: rsync user can read everything).
The project is located at https://github.com/hermanbanken/ldap-control and this issue is also on GitHub at https://github.com/hermanbanken/ldap-control/issues/1.
sudo is on OSX later versions.
sudo rsync .....
I have written a Cocoa app which uses libpcap to monitor network traffic. Since libpcap requires root privileges I was wondering what's the best way to give it root privileges (e.g. using Package Maker?). Would I be able to deploy it using a drag-and-drop installer or is Package Maker my only option?
Additionally I would like to know of the security risks posed by giving my app root permissions. The app also writes to disk (sqlite database) and I read that giving an app that writes to disk root privileges is not a good idea.
The recommended Apple way to do what you want is as follows:
factor out the stuff that requires privileged operation into a separate executable (that's the stuff that uses libpcap for you).
when the application needs to start the privileged exe, it creates an authorization reference and checks the user can authorize (known as pre-authorization) and passes an external reference to the authorization to the privileged exe.
when it first starts, the privileged exe gains authorization again before attempting to do the privileged stuff.
For the above to work, the privileged exe has to be installed as owned by root with the setuid bit set. You can either do this with package maker or you can create what Apple terms a self repairing helper tool. This is a tool that checks if it is running as root and if not calls itself via AuthorizationExecuteWithPrivileges to repair its setuid bit and ownership. Then it does the authorization for the operation and performs the operation.
If you use the self repairing tool, you can bundle it in with your application and use a drag and drop installation process.
I strongly advise you to read the whole of the Authorization Programming Guide. It talks about all this stuff in more detail and includes some example code.
The problem is that in our clients their normal user doesn't have administrator privileges so when they have to install or update our programs they have to log again as administrator to install them and then log as their user which is cumbersome...
As some updates are automatic the "run as" solution isnt a valid one...
One good idea would be to mark a folder as "admin folder" so all the exes executed from that folder run as administrator (having configured the admin account previously)
or a configurable a list of executable names that must run as administrator (i say names because it could be different installers with different hash but with a generic exe name that identifies it as ours)
Does anyone know a program or windows configuration or c# code to achieve something like this?
It seems nobody knows how to do it or doesnt want to tell because its a security hole...ironically having this escalating privileges hole would be better than having the user as administrator for everithing :S... (Appart from not being a valid solution for our clients)