Rudder

Nicolas PERRON wrote:

Is these permissions set by packaging ?

No, this ticket is about permissions on files generated by the webapp. The contents of /var/rudder/share and /var/rudder/cfengine-community/inputs, basically.

So long as the Rudder server is secure, no access to these files can happen. When they are copied to nodes, their permissions should be changed there, but there may be a gap in between when they are world readable. Demoting priority a bit, but we should still fix this soon.

François ARMAND wrote:

Well, we don't have the possibility to control Unix File permission in Java (the platform independent thing).

The possibility are:

• 1) use a different umask before starting the JVM, but that will impact ALL files created by applications under that JVM, what seems to be a bad idea ;
• 2) run a chmod from the JVM after each creation, what is possible but not a too good idea (JVM calling Unix process is utterly slow)
• 3) using JDK 7 to be able to use the NIO API (java.nio.file.attribute.PosixFileAttributes / Files.setPosixFilePermissions)
• 4) have the permissions set by a CFEngine running on the server :)

And I believe I don't know anything else.

If 4) is not possible, I can implement 2), but it's likelly to be noticeable.

4) is possible, but I think it's already the case (not sure). However, this is not a good solution in a security problem: if we're worried about malicious users reading the files, we should not allow them to be in mode 755 at all, not even for 1 second. 2) is not sufficient for the same reason.

3) is not possible as the JRE 7 is not easily available (in distribution package repos) for all (or even most) of our supported server operating systems.

By elimination, it seems to me that 1) is the most sensible. If we assume that other malicious users may be on the Rudder server, and try and protect our data from them, we should certainly not create any files in 755. It is also easy to implement.

Can you see any reasons why this would have other negative impacts?

Matthieu, can you please add a configuration in 2.4 to force Jetty's umask to 027 (in it's init script I presume). The simplest way to test will be to regenerate promises and check their permission - they should not have 640 perms.

Well, I just tried now and Rudder did generate promises with these rights:

drwxr-xr-x 12 root root 4,0K juin 21 17:37 .
drwxr-xr-x 14 root root 4,0K avril 25 06:42 ..
drwx------  3 root root 4,0K juin 21 17:36 06da3556-5204-4bd7-b3b0-fa5e7bcfbbea

700 seems like a perfect mode to me :) I do not see any trouble here.

Same goes for /var/rudder/cfengine-community/inputs by the way:

-rw------- 1 root root 3,2K juin 21 17:37 /var/rudder/cfengine-community/inputs/failsafe.cf
-rw------- 1 root root  16K juin 21 17:37 /var/rudder/cfengine-community/inputs/promises.cf

Are we really sure there is a problem here ?

(This test was done on orchestrator-3, i'll try on orch-2 as well)

Well, that is quite a surprise, indeed orch-3 seems to be the only orchestrator doing this. The init script might have been polluted by my own umask maybe.

Whatever, I'm on it then.

Damn. Jetty seems to ignore the umask.

It seems we are going to need another approach, or tolerate the delay before a cf-agent run.

Applied in changeset commit:9dcaf567df0751c659484b43948b45804408423f.

Looks good to me!