4 ms·

MACs come in many different flavors. E.g. AppArmor is very easy to administrate an provides security over running 'random' applications without MAC.

bandrami 10y ago
There's two separate issues here, both of which apply: 1. A knob that can't be configured can't be misconfigured (IIRC Debian had a hole in its default selinux config for years that created a vulnerability selinux-less machines didn't have) 2. (This was more what I meant) the promise that makes people like MACs is that you no longer need a single all-powerful root user to do everything (this bleeds into ACLs and capabilities, too), but keeps running into two icebergs: 2a. Somebody still has to administer those controls, and so can effectively become that all-powerful root, and 2b. The only stuff I actually care about is the actual data that the application being sandboxed can access to begin with. This gives us the particularly pointless exercise in which somebody who steals my laptop can impersonate me on gmail and social media, empty my bank account, and delete all my github repos, but can't change the laptop's time zone. The system files that I can download for free at any time are protected, but the manuscript for my novel is not.
- dom0 10y ago
  > capabilities Well. There just aren't many useful caps to begin with. For example, consider backups. You'd want the backup system to have full read access to everything. Well. You can't do that with capabilities. You only get DAC_OVERRIDE, which is one of the many root-equivalent caps in Linux. Probably half of them are.
  - ori_b 10y ago
    Even better, in my opinion, is that many of the caps that you would use to sandbox an app (like PID and FS namespaces) require you to have the sysadmin capability set on the process. Great. You need to give a process more or less root so that it can deny itself privileges.
    - dom0 10y ago
      The idea is probably that the service manager (systemd) manages the NSs for the applications contained therein. systemd of course doesn't have to check it's own privileges.
      - bandrami 10y ago
        GNU PIES, however, does check its own privileges. I have no idea why it didn't get a harder look during the init wars. I get that Shepherd "isn't there yet", but IMO Pies is.
      - ori_b 10y ago
        But the binaries I want this on aren't services.
  - bandrami 10y ago
    Which leads us to the full absurdity of CAP_SYS_ADMIN, which at this point even the kernel team admits is "basically root"
  - aaronmdjones 10y ago
    You only need CAP_DAC_READ_SEARCH for backups.

bandrami 10y ago

There's two separate issues here, both of which apply: 1. A knob that can't be configured can't be misconfigured (IIRC Debian had a hole in its default selinux config for years that created a vulnerability selinux-less machines didn't have) 2. (This was more what I meant) the promise that makes people like MACs is that you no longer need a single all-powerful root user to do everything (this bleeds into ACLs and capabilities, too), but keeps running into two icebergs: 2a. Somebody still has to administer those controls, and so can effectively become that all-powerful root, and 2b. The only stuff I actually care about is the actual data that the application being sandboxed can access to begin with. This gives us the particularly pointless exercise in which somebody who steals my laptop can impersonate me on gmail and social media, empty my bank account, and delete all my github repos, but can't change the laptop's time zone. The system files that I can download for free at any time are protected, but the manuscript for my novel is not.

dom0 10y ago
> capabilities Well. There just aren't many useful caps to begin with. For example, consider backups. You'd want the backup system to have full read access to everything. Well. You can't do that with capabilities. You only get DAC_OVERRIDE, which is one of the many root-equivalent caps in Linux. Probably half of them are.
- ori_b 10y ago
  Even better, in my opinion, is that many of the caps that you would use to sandbox an app (like PID and FS namespaces) require you to have the sysadmin capability set on the process. Great. You need to give a process more or less root so that it can deny itself privileges.
  - dom0 10y ago
    The idea is probably that the service manager (systemd) manages the NSs for the applications contained therein. systemd of course doesn't have to check it's own privileges.
    - bandrami 10y ago
      GNU PIES, however, does check its own privileges. I have no idea why it didn't get a harder look during the init wars. I get that Shepherd "isn't there yet", but IMO Pies is.
    - ori_b 10y ago
      But the binaries I want this on aren't services.
- bandrami 10y ago
  Which leads us to the full absurdity of CAP_SYS_ADMIN, which at this point even the kernel team admits is "basically root"
- aaronmdjones 10y ago
  You only need CAP_DAC_READ_SEARCH for backups.