Timeline for Executing commands in an elevated bash process by writing to the standard input of its parent script process
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 13, 2016 at 16:28 | comment | added | marcan |
Essentially, the moment you start a root shell, you are giving any other process running as that user root access. Encryption won't help, because any other process running as that user could use something like ptrace to read all the encryption keys off your app. This is no different from doing a simple sudo -i which has the same problem. What you can do is write a secure application that runs as root and limits the actions that the user can take through it. Whether this makes sense or not depends on whether that would meaningfully increase security for your particular use case.
|
|
| May 13, 2016 at 10:29 | comment | added | Tony George | I was trying to create a background root shell from an application which could be used to run root commands. This way the user would be prompted only once for the password and the main application itself could be started as a normal user. It seems to be a bad idea to start a bash process in this way as it could be misused by other applications. Maybe I can encrypt the commands being passed between the application and the root shell so that the root shell will only execute the commands sent by the application? Thanks for explaining the behaviour of pipes. I need to experiment more with this. | |
| May 13, 2016 at 10:22 | comment | added | Tony George | This makes sense. I need to read up more on file descriptors in Linux. They work a little differently than I thought they would. Thank you for the detailed answer. It was very informative. | |
| May 13, 2016 at 10:09 | vote | accept | Tony George | ||
| May 13, 2016 at 9:55 | history | answered | marcan | CC BY-SA 3.0 |