Block cron from ALL at the beginning

[jjackzhn]

Per security recommendation raised during ISL vetting. Currently implemented in Hiera for isl-control.

The goal with this is to prevent anything with LOCAL allowed from accessing cron.

[jakerundall]

We have at least one use case where non-root users need to run cron (Nightingale Postgres nodes). I think this will break that? We would need some kind of allow-first rules to form a full access.conf like this, I think:

# this one goes first just because it's specified first in the profile?
+ : root : LOCAL
# NEW: some kind of allow-first, which probably won't work with the current approach?
+ : postgres : cron crond
# deny-first rules
- : (all_disabled_usr) : ALL
- : cron crond : ALL
# allow rules
...
# deny rules
...

Thoughts?

[jjackzhn]

@jakerundall Good question. I did test that the root@LOCAL line does always get added at the beginning.
I can try to implement a allow_first type but I wonder how that will interact with deny_first...

[bsper2]

I did some testing since I needed an allow-first functionality on mforge for SVCPLAN-4203.

Added it with:

  ensure_resources( 'pam_access::entry', $allow_first_rules,
    { 'permission' => '+',
      'position'   => 'before',
    }
  )

This didn't work, the ordering of the rules came after deny_first_rules in my testing.

[jjackzhn]

Further testing and ideas:

• Probably due to its placement in the code, the Default Allow rule will always fail on the first run with zero rules in access.conf. Default Deny comes after and establishes a base for all the other rules to act upon. Deny First rules will succeed and get placed at the beginning of the file. Then on a second run, the Default Allow rule gets added to the correct place because it's the only one competing for the placement.
• Allow First doesn't work because it will be competing with Deny First for the "before" placement. The result is either random or decided by the order Puppet gets to parse each rule.

Therefore, I propose ef7cb86. This would ideally let Default Deny always be the first rule inserted, so the first run won't fail; and chaining Default Allow after Deny First should remove the race condition of both of them executing in the same Puppet run.

[billglick]

@jjackzhn Can this be closed? It seems very old.