4 ms·

This is not a good advice. You'll basically get Ubuntu that didn't have SELinux in the first place, and most people don't care. SELinux is difficult to build

This is not a good advice. You'll basically get Ubuntu that didn't have SELinux in the first place, and most people don't care. SELinux is difficult to build from scratch but there are decent tools to build your policy in an automated fashion. The advice should be this: Don't have time to deal with SELinux at the moment? Switch to permissive policy and deal with it later. I included SELinux as one big chapter in my book Deployment from Scratch rather than skipping on it.

elevader 4y ago
That's not really great advice either, temporary solutions/workarounds have a tendency of sticking around permanently.
- strzibny 4y ago
  I say this, because it's very hard to write the policy yourself at the beginning. So let the system run for a week and then use the tools to build the policy for you. I wish it's easier to sit down and write it, but it's not atm.
  - tremon 4y ago
    How does that work? If you run selinux without a policy, you also get no type transitions and no file labels. That means that after a week, you only have a list of things your system does, with every action coupled to the init_t domain (or possibly even kernel_t), and file access targeted at unlabeled_t (unmanaged_t?). At the bare minimum, you need a base policy that already contains separate type contexts for each of your services, file contexts to apply to the service daemon binaries, and type transitions so that each service gets run in its proper context. If your daemons run in the wrong context, then immortalizing that in policy with e.g. audit2allow only deepens the swamp you're in. I don't think there's any practical way to build an selinux policy from scratch by just running your system and recording it, even if the tools allow you to do that. You can only start from your OS' reference policy or indeed write the initial base policy by hand.

elevader 4y ago

That's not really great advice either, temporary solutions/workarounds have a tendency of sticking around permanently.

strzibny 4y ago
I say this, because it's very hard to write the policy yourself at the beginning. So let the system run for a week and then use the tools to build the policy for you. I wish it's easier to sit down and write it, but it's not atm.
- tremon 4y ago
  How does that work? If you run selinux without a policy, you also get no type transitions and no file labels. That means that after a week, you only have a list of things your system does, with every action coupled to the init_t domain (or possibly even kernel_t), and file access targeted at unlabeled_t (unmanaged_t?). At the bare minimum, you need a base policy that already contains separate type contexts for each of your services, file contexts to apply to the service daemon binaries, and type transitions so that each service gets run in its proper context. If your daemons run in the wrong context, then immortalizing that in policy with e.g. audit2allow only deepens the swamp you're in. I don't think there's any practical way to build an selinux policy from scratch by just running your system and recording it, even if the tools allow you to do that. You can only start from your OS' reference policy or indeed write the initial base policy by hand.