Closed zehric closed 4 years ago
Mikaela
commented
5 years ago Personally I just have a script copying the certificates around and reloading configs.
If Syncplay de-elevated to a different user, would it require a restart for certificate renewal?
daniel-123
commented
5 years ago Well, you certainly should not run Syncplay server as root.
My own solution was to give the user which starts the Syncplay server access to the certs it needs. Like @Mikaela mentions - this also facilitates automatic cert rotation. This doesn't work well with the idea of de-elevating a process. At least unless we would leave such process running. That said - main problem with this approach is that at least from what I understand it would require a fair bit of work, possibly up to need to refactor important parts of server code.
I could see a wrapper that temporarily creates a cert copy akin to what @Mikaela does as sensible and not requiring too much work to implement.
As a last comment and as far as I understand - since the actual private key needs to reside in memory of the process that actually handles the connection - isn't denying access to exact same data (just as a file rather than python variable) not going to improve security appreciably? IMHO if you are far enough in to read a file from python process you took over, you also are likely to be able to read its variables anyway.
I'd like for few others to perhaps chime in with comments about where to proceed with this. Especially as Syncplay in first place doesn't need to transfer sensitive information so if your certs are used for some other important service I'd say running Syncplay without TLS or having a separate certificate for subdomain might be the best option (it's at very least a workaround that's available right now).
Et0h
commented
5 years ago I agree that running an application as root unnecessarily goes against best security practice and so am grateful to @zehric for raising this issue. To address this concern I have updated https://github.com/Syncplay/syncplay/wiki/TLS-support to include a link to this issue page so that those wishing to run a Linux server with TLS can consult advice on how to do so without running Syncplay as root.
Taking into account the comments from @mikaela and @dan-123 I don't think any change to Syncplay's behaviour is necessary and am not in favour of starting as root then de-escalating due to the issues that causes to certificate reloading.
If someone knew of a reliable method of detecting that the server is running as root (does os.geteuid()==0 do the trick?) then they might be able to make a PR to the Syncplay server code to warn server admins when they are running a Syncplay server as root and direct them to this issue page (or an updated wiki page) for advice. I don't use Linux, so I'll leave that to someone who does.
daniel-123
commented
5 years ago @Et0h: Speaking as an old Linux guy - not running Syncplay as root should be the obvious path to take. Old server guide we link on the main page also suggests to run it as user solely dedicated to that purpose. (Side note - that guide could use some refresh)
From that perspective I find any extra warning to be superfluous. But from perspective of somebody new to Linux a message like this could be useful.
My understanding of os.geteuid()==0 is that it would be a good enough check. Technically you should have a separate account that has bare minimum privileges required to run Syncplay, but that starts getting uncomfortably close to SELinux policies and other serious security tools which currently are completely out of scope here.
... or leaving our certs and keys readable by the process that is running syncplay. I suggest doing what lighttpd and most http servers do which is start elevated to read the certs and then de-elevating themselves to a different user.