3 ms·

SELinux does not rely on the usual UID/GID to determine what a process can do. System services, even when running as "root", are running as confined users in SE

SELinux does not rely on the usual UID/GID to determine what a process can do. System services, even when running as "root", are running as confined users in SELinux. Confined root cannot do anything which SELinux policy does not allow it to do. This means you can let sshd create new sessions for non-root users while still blocking it from doing the other things which unconfined root would be able to do. This is still a lot of power but it's not the godlike access which a person logged in as (unconfined) root has.

quotemstr 3y ago
Doesn't matter. A malicious sshd able to run commands arbitrary users can just run malicious commands as those users. We'd need something more like a cryptographically attested setreuid() and execve() combination that would run only commands signed with the private key of the intended user. You'd want to use a shared clock or something to protect against replay attacks
- kbolino 3y ago
  Yes, this won't directly protect against an attacker whose goal is to create a botnet, mine some crypto on your dime, etc. However, it will protect against corruption of the O/S itself and, in tandem with other controls, can limit the abilities an attacker has, and ensure things like auditing are still enforced (which can be tied to monitoring, and also used for forensics). Whether it's worth it or not depends on circumstances. In many cloud environments, nuking the VM instance and starting over is probably easier than fiddling with SELinux.
  - CanaryLayout 3y ago
    even easier is to STOP HOSTING SSHD ON IPV4 ON CLEARNET at minimum, ipv6 only if you absolutely must do it (it absolutely cuts the scans way down) better is to only host it on vpn even better is to only activate it with a portknocker, over vpn even better-better is to set up a private ipv6 peer-to-peer cloud and socat/relay to the private ipv6 network (yggdrasil comes to mind, but there's other solutions to darknet) your sshd you need for server maintenance/scp/git/rsync should never be hosted on ipv4 clearnet where a chinese bot will find it 3 secs after the route is established after boot.
    - alrs 3y ago
      Who cares about scans? Who cares if a scan comes in 4 or 6?
      - kbolino 3y ago
        Forget IPv6, just moving SSH off of port 22 stops the vast majority of drive-by attacks against sshd on the open Internet.
      - account42 3y ago
        I imagine it stops some non-targeted attempts that simply probe the entire v4 range, which is not feasible with v6. But yeah, not really buying you much, especially if there is any publicly listed service on that IP.
    - dvdkon 3y ago
      How about making ssh as secure as (or more secure than) the VPN you'd put it behind? Considering the amount of vulnerabilities in corporate VPNs, I'd even put my money on OpenSSH today. It's not like this is SSH's fault anyway, a supply chain attack could just as well backdoor some Fortinet appliance.
      - formerly_proven 3y ago
        Honestly the only VPN I'd rank above ssh in terms of internet-worthiness is WireGuard.
      - versteegen 3y ago
        Defence in depth. Which of your layers is "more secure" isn't important if none are "perfectly secure", so having an extra (independent) layer such as a VPN is a very good idea.
        dvdkon 3y ago
        You have to decide when to stop stacking, otherwise you'd end up gating access behind multiple VPNs (and actually increasing your susceptibility to hypothetical supply-chain attacks that directly include a RAT). I'd stop at SSH, since I don't see a conceptual difference to how a VPN handles security (unless you also need to internally expose other ports).

quotemstr 3y ago

Doesn't matter. A malicious sshd able to run commands arbitrary users can just run malicious commands as those users. We'd need something more like a cryptographically attested setreuid() and execve() combination that would run only commands signed with the private key of the intended user. You'd want to use a shared clock or something to protect against replay attacks

kbolino 3y ago
Yes, this won't directly protect against an attacker whose goal is to create a botnet, mine some crypto on your dime, etc. However, it will protect against corruption of the O/S itself and, in tandem with other controls, can limit the abilities an attacker has, and ensure things like auditing are still enforced (which can be tied to monitoring, and also used for forensics). Whether it's worth it or not depends on circumstances. In many cloud environments, nuking the VM instance and starting over is probably easier than fiddling with SELinux.
- CanaryLayout 3y ago
  even easier is to STOP HOSTING SSHD ON IPV4 ON CLEARNET at minimum, ipv6 only if you absolutely must do it (it absolutely cuts the scans way down) better is to only host it on vpn even better is to only activate it with a portknocker, over vpn even better-better is to set up a private ipv6 peer-to-peer cloud and socat/relay to the private ipv6 network (yggdrasil comes to mind, but there's other solutions to darknet) your sshd you need for server maintenance/scp/git/rsync should never be hosted on ipv4 clearnet where a chinese bot will find it 3 secs after the route is established after boot.
  - alrs 3y ago
    Who cares about scans? Who cares if a scan comes in 4 or 6?
    - kbolino 3y ago
      Forget IPv6, just moving SSH off of port 22 stops the vast majority of drive-by attacks against sshd on the open Internet.
    - account42 3y ago
      I imagine it stops some non-targeted attempts that simply probe the entire v4 range, which is not feasible with v6. But yeah, not really buying you much, especially if there is any publicly listed service on that IP.
  - dvdkon 3y ago
    How about making ssh as secure as (or more secure than) the VPN you'd put it behind? Considering the amount of vulnerabilities in corporate VPNs, I'd even put my money on OpenSSH today. It's not like this is SSH's fault anyway, a supply chain attack could just as well backdoor some Fortinet appliance.
    - formerly_proven 3y ago
      Honestly the only VPN I'd rank above ssh in terms of internet-worthiness is WireGuard.
    - versteegen 3y ago
      Defence in depth. Which of your layers is "more secure" isn't important if none are "perfectly secure", so having an extra (independent) layer such as a VPN is a very good idea.
      - dvdkon 3y ago
        You have to decide when to stop stacking, otherwise you'd end up gating access behind multiple VPNs (and actually increasing your susceptibility to hypothetical supply-chain attacks that directly include a RAT). I'd stop at SSH, since I don't see a conceptual difference to how a VPN handles security (unless you also need to internally expose other ports).