0

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?

Paulo Boaventura
  • 1,365
  • 1
  • 9
  • 29
Gaucho
  • 1,328
  • 1
  • 17
  • 32
  • 1
    Why can't you use a group-readable settings file and add the two users in the same group ? – Vincent Fourmond Apr 03 '21 at 12:19
  • 1
    Or even a world-readable file ? Or is this not possible because of possible security/privacy issues ? – Vincent Fourmond Apr 03 '21 at 12:20
  • @vincent fourmond, if the settings file is readable by user1 then I miss one of the two requirements detailed in the question. – Gaucho Apr 03 '21 at 12:22
  • Settings File can not be read for security/privacy issues. – Gaucho Apr 03 '21 at 12:23
  • 1
    I had not seen the negative... This is going to be tough. Breakable easily at best, very bad security issues if this is not done perfectly fine. Can you explain what you're trying to achieve ? This looks like a XY question. – Vincent Fourmond Apr 03 '21 at 12:25
  • 1
    I mean, if you're writing the program yourself, you can make the program setgid, and make the file group-readable, and drop the privileges are soon as the file is read. – Vincent Fourmond Apr 03 '21 at 12:27
  • The scope is to protect settings file content, but allow the user to use the application. I don't know how to better explain it. Another way to place the question in a different way 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 input and send standard output of the exe launched by root? – Gaucho Apr 03 '21 at 12:34
  • @vincent please better describe setgid approach. If the exe is launched by user1(user without the privilege to read settings file), how should it be set as readable? The exe can not contain root password. – Gaucho Apr 03 '21 at 12:39

1 Answers1

1

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:

  1. create a custom group private-group (as root):
~ addgroup private-group
  1. 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
  1. 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.

Vincent Fourmond
  • 3,038
  • 1
  • 22
  • 24