3 ms·

This is a pretty lax policy IMHO, you can go much farther. These days I usually start with this, it's much more strict: https://news.ycombinator.com/item?id=29

This is a pretty lax policy IMHO, you can go much farther. These days I usually start with this, it's much more strict: https://news.ycombinator.com/item?id=29976096 https://news.ycombinator.com/item?id=29976096 Or simply follow whatever `systemd-analyze security` recommends, just make sure you run it on a system with recent systemd.

westurner 5y ago
Which distro has the best out-of-the-box output for:? systemd-analyze security Is there a tool like `audit2allow` for systemd units? selinux/python/audit2allow/audit2allow: https://github.com/SELinuxProject/selinux/blob/master/python/audit2allow/audit2allow https://github.com/SELinuxProject/selinux/blob/master/python... https://stopdisablingselinux.com/ https://stopdisablingselinux.com/
- 5e92cb50239222b 5y ago
  > Which distro has the best out-of-the-box output I haven't seen any difference between distributions with the same systemd version. Anything with a recent one should do fine. More recent than RHEL8, mind you (which is on systemd 239): for example, a syscall allow/deny analysis is buggy there and asks you to enable some protections, and then disable them. The same unit is analyzed correctly on my desktop with v250 (I use the popular rolling release distribution). I haven't seen anything like audit2allow. It's probably not especially necessary because of the difference in philosophies: SELinux is deny by default, while in systemd you're playing whack-a-mole anyway, and are expected to add directives one by one until the application stops working. Unit logs usually make it obvious if something was denied.
  - Arnavion 5y ago
    The usual way I've seen (and do myself) is to just let the process be killed and have its coredump taken, then `coredumpctl gdb $process_name -A '-ex "print $rax" -ex "quit"'` to get the syscall number, then check `systemd-analyze syscall-filter` for whether I want to allow just that one syscall or the whole group it's in.
    - growse 5y ago
      > The usual way I've seen (and do myself) is to just let the process be killed and have its coredump taken, then `coredumpctl gdb $process_name -A '-ex "print $rax" -ex "quit"'` to get the syscall number, then check `systemd-analyze syscall-filter` for whether I want to allow just that one syscall or the whole group it's in. Another approach would be to set SystemCallLog= to be the opposite of SystemCallFilter= (negate each group with ~) and then you'll see the call (and caller) in the journal.
      - Arnavion 5y ago
        At least on my distro (OpenSUSE Tumbleweed, systemd 249, kernel 5.16.0), SystemCallLog doesn't fire for calls that are filtered; the process is killed first. Even if I set SystemCallErrorNumber=EPERM I don't see the audit log generated. The log only gets generated if the syscall wasn't filtered.
        growse 5y ago
        How strange. If I take a service and set SystemCallFilter=@basic-io SystemCallLog=~@basic-io and then restart it, I get a bunch of audit SECCOMP log messages (and the service fails to start): audit[1185972]: SECCOMP auid=4294967295 uid=63946 gid=63946 ses=4294967295 subj==unconfined pid=1185972 comm="(t-online)" exe="/usr/lib/systemd/systemd" sig=0 arch=c000003e syscall=59 compat=0 ip=0x7f5c632f66c7 code=0x7ffc0000 This is debian bullseye and systemd 247. I wonder if your audit logs are going somewhere else?
      - westurner 5y ago
        FWIU, e.g. sysdig is justified atop whichever MAC system. In the SELinux MAC system on RHEL and Debian, in /etc/config/selinux, you have SELINUXTYPE=minimal|targeted|mls. RHEL (CentOS and Rocky Linux) and Fedora have SELINUXTYPE=targeted out-of-the-box. The compiled rulesets in /etc/selinux/targeted are generated when [...]. With e.g gnome-system-monitor on a machine with SELINUX=permissive|enforcing, you can right-click the column header in the process table to also display the 'Security context' column that's also visible with e.g. `ps -Z`. The stopdisablingselinux video is a good SELinux tutorial. I'm out of date on Debian/Ubuntu's policy set, which could also probably almost just be sed'ed from the current RHEL policy set. > * SELinux is deny by default, while in systemd you're playing whack-a-mole anyway, and are expected to add directives one by one until the application stops working. Unit logs usually make it obvious if something was denied.* DENY if not unconfined is actually the out-of-the-box `targeted` config on RHEL and Fedora. For example, Firefox and Chrome currently run as unconfined processes. While decent browsers do do their own process sandboxing, SELinux and/or AppArmor and/or 'containers' with a shared X socket file (and drop-privs and setcap and cgroups and namespaces fwtw) are advisable atop really any process sandboxing? Given that the task is to generate a hull of rules that allow for the observed computational workload to complete with least-privileges, if you enable like every rule and log every process hitting every rung on the way down while running integration tests that approximate the workload, you should end up with enough rule violations in the log to even dumbly generate a rule/policy set without the application developer's expertise around to advise on potential access violations to allow. From https://github.com/draios/sysdig https://github.com/draios/sysdig : > "Sysdig instruments your physical and virtual machines at the OS level by installing into the Linux kernel and capturing system calls and other OS events. Sysdig also makes it possible to create trace files for system activity, similarly to what you can do for networks with tools like tcpdump and Wireshark. Probably also worth mentioning: "[BETA] Auditing Sysdig Platform Activities" https://docs.sysdig.com/en/docs/developer-tools/beta-auditing-sysdig-platform-activities/ https://docs.sysdig.com/en/docs/developer-tools/beta-auditin... A bit of SELinux: # /etc/selinux/config SELINUXTYPE=targeted SELINUX=permissive $# touch /.autorelabel # `restorecon /` at boot $# reboot $# setenforce 1 # redundant $ sudo aureport --avc $ journalctl --system -u auditd $ journalctl --system -o json-seq --reverse $ journalctl --system --grep "AVC" --reverse journalctl -fa _TRANSPORT=audit journalctl -fa _TRANSPORT=audit --grep AVC journalctl -a _TRANSPORT=audit --grep 'AVC avc: denied' -o json | pyline -m json 'json.dumps(json.loads(l), indent=2, sort_keys=True)'
- deleted 5y ago
  [deleted]
- goodpoint 5y ago
  Debian does a lot of sandboxing.
  - aidenn0 5y ago
    To the point where it breaks logind on NIS setups...
d2wa 5y ago
This is a getting started/101 introduction; it also talks about and recommends systemd-analyze security. There’s a link to part two at the bottom of the article that goes deeper into things.
DyslexicAtheist 5y ago
any system that starts security by blacklisting instead of whitelisting tends to be doomed by upcoming changes.

westurner 5y ago

Which distro has the best out-of-the-box output for:? systemd-analyze security Is there a tool like `audit2allow` for systemd units? selinux/python/audit2allow/audit2allow: https://github.com/SELinuxProject/selinux/blob/master/python/audit2allow/audit2allow https://github.com/SELinuxProject/selinux/blob/master/python... https://stopdisablingselinux.com/ https://stopdisablingselinux.com/

5e92cb50239222b 5y ago
> Which distro has the best out-of-the-box output I haven't seen any difference between distributions with the same systemd version. Anything with a recent one should do fine. More recent than RHEL8, mind you (which is on systemd 239): for example, a syscall allow/deny analysis is buggy there and asks you to enable some protections, and then disable them. The same unit is analyzed correctly on my desktop with v250 (I use the popular rolling release distribution). I haven't seen anything like audit2allow. It's probably not especially necessary because of the difference in philosophies: SELinux is deny by default, while in systemd you're playing whack-a-mole anyway, and are expected to add directives one by one until the application stops working. Unit logs usually make it obvious if something was denied.
- Arnavion 5y ago
  The usual way I've seen (and do myself) is to just let the process be killed and have its coredump taken, then `coredumpctl gdb $process_name -A '-ex "print $rax" -ex "quit"'` to get the syscall number, then check `systemd-analyze syscall-filter` for whether I want to allow just that one syscall or the whole group it's in.
  - growse 5y ago
    > The usual way I've seen (and do myself) is to just let the process be killed and have its coredump taken, then `coredumpctl gdb $process_name -A '-ex "print $rax" -ex "quit"'` to get the syscall number, then check `systemd-analyze syscall-filter` for whether I want to allow just that one syscall or the whole group it's in. Another approach would be to set SystemCallLog= to be the opposite of SystemCallFilter= (negate each group with ~) and then you'll see the call (and caller) in the journal.
    - Arnavion 5y ago
      At least on my distro (OpenSUSE Tumbleweed, systemd 249, kernel 5.16.0), SystemCallLog doesn't fire for calls that are filtered; the process is killed first. Even if I set SystemCallErrorNumber=EPERM I don't see the audit log generated. The log only gets generated if the syscall wasn't filtered.
      - growse 5y ago
        How strange. If I take a service and set SystemCallFilter=@basic-io SystemCallLog=~@basic-io and then restart it, I get a bunch of audit SECCOMP log messages (and the service fails to start): audit[1185972]: SECCOMP auid=4294967295 uid=63946 gid=63946 ses=4294967295 subj==unconfined pid=1185972 comm="(t-online)" exe="/usr/lib/systemd/systemd" sig=0 arch=c000003e syscall=59 compat=0 ip=0x7f5c632f66c7 code=0x7ffc0000 This is debian bullseye and systemd 247. I wonder if your audit logs are going somewhere else?
    - westurner 5y ago
      FWIU, e.g. sysdig is justified atop whichever MAC system. In the SELinux MAC system on RHEL and Debian, in /etc/config/selinux, you have SELINUXTYPE=minimal|targeted|mls. RHEL (CentOS and Rocky Linux) and Fedora have SELINUXTYPE=targeted out-of-the-box. The compiled rulesets in /etc/selinux/targeted are generated when [...]. With e.g gnome-system-monitor on a machine with SELINUX=permissive|enforcing, you can right-click the column header in the process table to also display the 'Security context' column that's also visible with e.g. `ps -Z`. The stopdisablingselinux video is a good SELinux tutorial. I'm out of date on Debian/Ubuntu's policy set, which could also probably almost just be sed'ed from the current RHEL policy set. > * SELinux is deny by default, while in systemd you're playing whack-a-mole anyway, and are expected to add directives one by one until the application stops working. Unit logs usually make it obvious if something was denied.* DENY if not unconfined is actually the out-of-the-box `targeted` config on RHEL and Fedora. For example, Firefox and Chrome currently run as unconfined processes. While decent browsers do do their own process sandboxing, SELinux and/or AppArmor and/or 'containers' with a shared X socket file (and drop-privs and setcap and cgroups and namespaces fwtw) are advisable atop really any process sandboxing? Given that the task is to generate a hull of rules that allow for the observed computational workload to complete with least-privileges, if you enable like every rule and log every process hitting every rung on the way down while running integration tests that approximate the workload, you should end up with enough rule violations in the log to even dumbly generate a rule/policy set without the application developer's expertise around to advise on potential access violations to allow. From https://github.com/draios/sysdig https://github.com/draios/sysdig : > "Sysdig instruments your physical and virtual machines at the OS level by installing into the Linux kernel and capturing system calls and other OS events. Sysdig also makes it possible to create trace files for system activity, similarly to what you can do for networks with tools like tcpdump and Wireshark. Probably also worth mentioning: "[BETA] Auditing Sysdig Platform Activities" https://docs.sysdig.com/en/docs/developer-tools/beta-auditing-sysdig-platform-activities/ https://docs.sysdig.com/en/docs/developer-tools/beta-auditin... A bit of SELinux: # /etc/selinux/config SELINUXTYPE=targeted SELINUX=permissive $# touch /.autorelabel # `restorecon /` at boot $# reboot $# setenforce 1 # redundant $ sudo aureport --avc $ journalctl --system -u auditd $ journalctl --system -o json-seq --reverse $ journalctl --system --grep "AVC" --reverse journalctl -fa _TRANSPORT=audit journalctl -fa _TRANSPORT=audit --grep AVC journalctl -a _TRANSPORT=audit --grep 'AVC avc: denied' -o json | pyline -m json 'json.dumps(json.loads(l), indent=2, sort_keys=True)'
deleted 5y ago
[deleted]
goodpoint 5y ago
Debian does a lot of sandboxing.
- aidenn0 5y ago
  To the point where it breaks logind on NIS setups...

d2wa 5y ago

This is a getting started/101 introduction; it also talks about and recommends systemd-analyze security. There’s a link to part two at the bottom of the article that goes deeper into things.

DyslexicAtheist 5y ago

any system that starts security by blacklisting instead of whitelisting tends to be doomed by upcoming changes.