Score:1

How to effectively secure a process and its forked children using setuid and setgid?

cn flag

I am trying to have all unix processes to be forked by a main process using different user/group identities. I do not want either the parent or child processes to be running as root so I want 2 other identities foo and bar to be used. foo should be used to run the main application and has limited access to the file system and then bar should be used by the forked processes and have even more limited access than foo.

The issue is when I try to call setuid or setgid after forking the child process I get back setuid failed: Operation not permitted no matter what I do. I have even confirmed that capsh --print shows I have the CAP_SETUID capability when running a shell as the foo user so I thought this should be allowed.

I must be misunderstanding the capabilities of this function and therefore I am using these tools incorrectly. What is the best way to create a relationship between processes and users in such a way that neither the parent or child processes run as root?

cn flag
"all unix processes". Unix != Linux. I would assume you create a systemd service that creates the parent as a user foo and that one spawns (a script or a 2nd systemd service) the childs. But there will always be a root owned process above the parent. Look at the apache service as an example (parent is root though but its childs are owned by use apache)
Matt Hintzke avatar
cn flag
Unfortuneately I tried this and it appears that WSL doesn't work with `systemd` and since I am using docker and need to develop on Windows it doesn't seem like I can use that as a solution.
cn flag
You reaaaaaaaaaaaally need to add WSL to the question :P What you want is likely not possible with WSL. It is not a substitute for a Linux install.
Matt Hintzke avatar
cn flag
Yeah sorry I mean the production software would not be using WSL so I didn't really think about that. But seeing how all development would be in windows it is a requirement I suppose. Thanks but it sounds like I'm not goibg to be able to do this effectively
NotTheDr01ds avatar
vn flag
@MattHintzke I don't normally recommend this path, but in your case I think it might warrant an exception. Since you are only using WSL for development purposes to mimic the production system, you might want to consider a Systemd-enablement script like [Genie](https://github.com/arkane-systems/genie). Again, I don't like using these Systemd scripts personally, since they change so much WSL functionality, but it might be the right path for you. These scripts all have the same general concept in that they create a container/namespace where Systemd is PID1 and change to that namespace.
Matt Hintzke avatar
cn flag
@NotTheDr01ds hmm ok I will take a look into that, thanks!
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.