You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
t3c sets a number of files with sensitive data: SSL keys, URI Signing keys, etc.
These files should be written with 0600 permissions, so users other than ats or root can't read them.
This should probably have a Secure field added to it, and the Make* func for secure files will set that to true. That's then passed to t3c-apply, which can read that field and set permissions to 0600 instead of the default 644, here:
We'll need to ensure t3c sets the file owner to ats as well. It may be not setting it, which will default to the user which ran t3c, which may be root, which would then break ATS which runs as the ats user which wouldn't be able to read the file anymore.
This isn't a major security issue, because it's highly unusual for operators to have any users without root access on caches. But it's at least a minor-to-medium concern.
I'm submitting a ...
new feature / enhancement request
Traffic Control components affected ...
Traffic Ops ORT
Current behavior:
t3c writes all files with 0644 permissions.
New behavior:
t3c writes sensitive files with 0600 permissions.
Minimal reproduction of the problem with instructions:
Run t3c-apply, observe sensitive files created with permissions readable by all users.
Anything else:
The text was updated successfully, but these errors were encountered:
t3c sets a number of files with sensitive data: SSL keys, URI Signing keys, etc.
These files should be written with 0600 permissions, so users other than ats or root can't read them.
All lib/go-atscfg files already return a
Cfg
struct with metadata: https://github.com/apache/trafficcontrol/blob/87dc34bd/lib/go-atscfg/atscfg.go#L103This should probably have a
Secure
field added to it, and theMake*
func for secure files will set that to true. That's then passed tot3c-apply
, which can read that field and set permissions to 0600 instead of the default 644, here:https://github.com/apache/trafficcontrol/blob/87dc34bd/cache-config/t3c-apply/torequest/torequest.go#L689
We'll need to ensure t3c sets the file owner to
ats
as well. It may be not setting it, which will default to the user which rant3c
, which may be root, which would then break ATS which runs as theats
user which wouldn't be able to read the file anymore.This isn't a major security issue, because it's highly unusual for operators to have any users without root access on caches. But it's at least a minor-to-medium concern.
I'm submitting a ...
Traffic Control components affected ...
Current behavior:
t3c
writes all files with0644
permissions.New behavior:
t3c
writes sensitive files with0600
permissions.Minimal reproduction of the problem with instructions:
Run
t3c-apply
, observe sensitive files created with permissions readable by all users.Anything else:
The text was updated successfully, but these errors were encountered: