[BUG] 3006.0 Debian and RPM salt-master package creates insecure permissions for salt user

[barneysowood]

Description

The release of 3006.0 included changes in the Debian and RPM packaging to create a user salt and config to run the salt-master processes under this user (#64045 and #64037).

Whilst running the master as a non-root user is an improvement, the benefit is seriously compromised by giving the salt user ownership of

• /etc/salt
• /var/log/salt
• /opt/saltstack/salt/
• /var/cache/salt/
• /var/run/salt

The main issues being:

• Write access to the python installation in /opt/saltstack/salt - the salt-master process should not be able to (persistently) modify the code it is running and more importantly, the code other salt processes (eg a local minion, salt-api, etc) are running as root.

• Read/write access to configuration and private data of other salt processes (eg salt-minion)

Setup

Install 3006.0 from Debian or RPM packages

• onedir packaging

Expected behavior

The salt-master process:

• Should not be able to modify the content of /opt/saltstack/salt
• Should not be able to read private data from other salt processes
• Should not be able to modify the config of other salt processes

Versions Report

• 3006.0

Additional context

• Ownership of /opt/saltstack/salt by salt user - it's not clear from [3006.x]User salt user/group for running salt-master #64037, but I suspect that this may have been done so that it is possible for the salt-master process to create bytecompiled python modules when it runs. It should be possible to create those at package install time and have them owned by root instead.
• Making /opt/saltstack/salt owned by root will mean that the MasterMinion won't be able to install python modules. I think that's a corner case/anti-feature, the default should be that the salt-master cannot modify the salt install and if users need to do that they can choose to modify ownership locally or run the master as root.
• It shouldn't be necessary for the salt-master to be able to write to anything other than /etc/salt/pki/master and /etc/salt/master.d under /etc/salt.
• It shouldn't really be necessary for the salt-master process to read any configs for other salt commands/daemons from /etc/salt, but it looks like it may currently need to read the minion config (see [BUG] 3006 Inconsistency with minion and master permissions on /etc/salt #64158)
• A design for handing users and permissions for running salt daemons as non-root users was outlined and accepted in SEP19 but this has not been followed in the current implementation.

[ITJamie]

The fact that it doesn't match SEP19 is a huge red flag for SEP's. whats the point of asking for community SEP buy in if its not being built to agreed spec's.

[anilsil]

Can this be tested with 3006.1?

[barneysowood]

Can this be tested with 3006.1?

@anilsil - 3006.1 doesn't resolve this. I'm going to re-integrate my changes in #64194 on top of 3006.1 as discussed here - #64174 (comment)

[anilsil]

Then it is all set for 3006.2

[Ch3LL]

Thanks for the PR @barneysowood , let me know if you want help adding test coverage

[barneysowood]

Thanks for the PR @barneysowood , let me know if you want help adding test coverage

Thanks, will do.

[dmurphy18]

Waiting on PR #64194 to close this issue

[Ch3LL]

closed by #64194