In general, it's impossible to know for sure - even a seemlingly-perfectly-safe program could have vulnerabilities that mean it can be used for arbitrary actions - but here are some things to check for:
Does the program do any of the following?
Reveal the contents of arbitrary files or devices.
Copy, move, write, or delete arbitrary files.
Set / modify ...
It essentially boils down to the halting problem, you can audit the code or reverse engineer the binary, however even if there are no "features" that let you execute arbitrary commands there could still be vulnerabilities in the binary or sudo itself that could lead to arbitrary command execution as root for the enabled users.
I'm wondering whether to make most of these files readable/executable
PHP files do not need to be executable. That could be worse than having the write permission.
Furthermore, in the specific directories mentioned (e.g., var generated vendor pub/static pub/media app/etc) write permissions are probably required (at least for some file types). I have not ...
Doing 'the inverse' seems like the more secure solution.
the backup function is the only function that the backup server
all incoming connections to the backup server are blocked
all outgoing connections (except the connection to the server being
backed-up) are blocked
the only process that the backup server performs is the backup process
Using groups for sudoers entries allows you to manage filesystem permissions (which by default are user- and group-based) in the same place as sudo rules. Using User_Alias instead of groups means all aspects of sudo rules are in the same place but makes it more difficult to manage sudo rules in the same space as filesystem permissions. So it's basically a ...
/dev/urandom uses a CSPRNG (Chacha20 last time I checked) to generate a stream of random data from an initial seed and allows the user to read an arbitrary number of bits from it. /dev/random pulls data out of a random pool that needs to be replenished.
It is possible to read from /dev/urandom before the system has enough entropy to provide a secure stream ...
Let's say we're exploiting buffer overflow in some foo function. Consider the following stack after overflowing the buffer, stopping at ret instruction in foo function:
"system" fn address <-- stack pointer
4 bytes of garbage
A reverse proxy is just an efficient tool, but not a magic bullet. When it is properly configured, it can ensure that only legal urls can be reached. But if you let anything pass through it will not protect much.
Security is hard because it is not only a matter of tools: any defect in the configuration of the security tools will open a breach. So the actual ...
Basically, you will depend on the expert(s) assessing the program security having a deep knowledge of what the programs that are allowed elevated rights can do.
The above sentence includes knowledge of the libraries used by the program and the system you are using (Linux? *BSD?).
Going down to a full source-code audit may not be needed. For a well-...
In general what you can think, instead of binaries is on syscalls. For example cat, more and less probably they will execute the syscalls, open, read, write, close and so on. On the other hand, if the binary (for example find) can execute other binaries, with the use of -exec parameter, the syscalls implied on this process are fork, exec, mmap, etc.. that ...
It takes only a few lines to test and the answer is clear: if the user knows the name of the file he can still read its meta data and content as long the permissions of the file itself allow it:
$ mkdir x
$ echo foo > x/y
$ ls -l x
-rw-rw-r-- 1 user user 4 Nov 21 18:44 y
$ chmod 0100 x
$ ls -l x
ls: cannot open directory 'x': Permission denied
Once the process is started, this is not possible. As mentioned the only way to do this is via redirection however that happens inside bash (as you've noted in the comments) not inside the process and thus does not fit as a solution for your question.
This question continues to receive occasional visits and upvotes, and I see that a few of the answers contain parts of the true answer, so I am creating a wiki answer that stitches it all together. A similar question has since been asked and answered at Unix.SE.
According to RH# 1225788, this is intended behavior:
It's by design that admin users (in the ...