5e92cb50239222b 4 years 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 4 years 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 4 years 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 4 years 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 4 years 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 4 years 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 :

        > "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-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)'
goodpoint 4 years ago

Debian does a lot of sandboxing.

  • aidenn0 4 years ago

    To the point where it breaks logind on NIS setups...