Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't fail setting log file ACLs with broken NSS backends #221

Merged
merged 1 commit into from
Aug 1, 2024

Conversation

hillu
Copy link
Collaborator

@hillu hillu commented Aug 1, 2024

Previously we would set POSIX ACL entries on log files by performing an early UID lookup and passing a stringified version of the UID to exacl::AclEntry::allow_user.

The exacl documentation states that names and decimal strings are accepted. Apparently, exacl would try to look up the decimal string using getpwnam() before considering that it should be parsed into a numeric value. Unfortunately, this could cause a fatal error and terminate the Laurel process:

fatal error 'Error writing to filter log: Custom { kind: Other, error: Custom { kind: Other, error: "Invalid ACL: entry 3: Connection refused (os errno 111)" } }' at src/bin/laurel/main.rs:300,38

We still do an early uid lookup but pass the original string to exacl instead of the decimal string.

Steps to reproduce: System is configured with sssd for AD integration; /etc/nsswitch.conf contains the following lines:

passwd:         files systemd sss
group:          files systemd sss
shadow:         files sss
gshadow:        files

If the machine es rebooted and sssd happens to come up after auditd, laurel fails to start and the error message above (or a similar one) is written to the auditd service's journal

This can also be reproduced without rebooting by stopping sssd and restarting auditd (so laurel is restarted).

@hillu hillu force-pushed the fix-acl branch 5 times, most recently from 8e2d1df to d32d39d Compare August 1, 2024 18:35
Previously we would set POSIX ACL entries on log files by performing
an early UID lookup and passing a stringified version of the UID to
`exacl::AclEntry::allow_user`.

The exacl documentation states that names and decimal strings are
accepted. Apparently, exacl would try to look up the decimal string
using `getpwnam()` before considering that it should be parsed into a
numeric value. Unfortunately, this could cause a fatal error and
terminate the Laurel process:

    fatal error 'Error writing to filter log: Custom { kind: Other, error: Custom { kind: Other, error: "Invalid ACL: entry 3: Connection refused (os errno 111)" } }' at src/bin/laurel/main.rs:300,38

We still do an early uid lookup but pass the original string to exacl
instead of the decimal string.

Steps to reproduce: System is configured with sssd for AD integration;
/etc/nsswitch.conf contains the following lines:

    passwd:         files systemd sss
    group:          files systemd sss
    shadow:         files sss
    gshadow:        files

If the machine es rebooted and sssd happens to come up after auditd,
laurel fails to start and the error message above (or a similar one)
is written to the auditd service's journal

This can also be reproduced without rebooting by stopping sssd and
restarting auditd (so laurel is restarted).
@hillu hillu merged commit 554662c into threathunters-io:master Aug 1, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant