Intersection based access control

Discussion in 'all things UNIX' started by Gullible Jones, Dec 18, 2014.

  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,459
    Just an idea:

    1. User applications normally run with the rights given them (DAC)
    2. setuid/setgid programs run with the rights of the owner/group (bypassing DAC)
    3. sandboxed programs run with the intersected (as in set theory) rights of their user/groups and invoking user/groups.

    So say we have an account 'bill' with membership in the groups users, audio, video, cdrom, and plugdev...

    And the account '_firefox' for the Firefox browser (and anything launched thereby), with membership in the groups audio and video.

    The intersection of the sets of the group memberships is just audio and video. This means that Firefox loses
    - access to hardware via cdrom and plugdev groups
    - access to Bill's files by not being the 'bill' user, or a member of 'users'

    So to run Firefox, Bill would set up the directories it has access to:
    $ mkdir ~/Downloads ~/.mozilla
    $ setfacl -m _firefox:rwx ~/Downloads ~/.mozilla
    $ setfacl -m default:_firefox:rwx ~/Downloads ~/.mozilla

    Firefox would be able to write to ~/.mozilla and ~/Downloads, and that's it, because only the intersected set of access rights would be respected. Likewise anything spawned by Firefox.

    Further thoughts:
    1. I think this might be doable without ACLs, but I'm not sure. It might hinge on the same directory traversal/absolute path issue that kickboxer ran into.
    2. When you get down to it, this is a lot like AppArmor, but less flexible. I'm not sure there's actually a good reason to have something like this...
    3. Especially seeing as it would probably require a kernel patch, which defeats the purpose of trying to kludge my way to RBAC without resorting to a custom kernel. But hey, thought experiments are fun.
     
  2. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,459
    So, apparently this is really a kind of diametric opposite of RBAC, where privileges are lost instead of gained?

    http://unix.stackexchange.com/quest...-as-the-system-administrator-root/21698#21698

    BTW it's interesting that Solaris has that pfexec command. Reading up on it, it basically looks like Linux "capabilities" but applied on the basis of user + executable, rather than just user (via group permissions) or just executable (via setcap attributes).

    Darn, I really need to read up on the theory of this stuff though. I wonder if it would be possible to tack on a pure userspace implementation of RBAC, via some sudo-esque command?

    (That actually seems rather like Polkit/pkexec, except that Polkit is overcomplicated to the point of being stark raving mad. I mean, it uses configuration files written in Javascript. Seriously!)

    Edit: I need to start yet another thread for this.

    Edit 2: no wait, this can't be implemented in userspace, as spawned programs will inherit the elevated permissions. D'oh! N/M.
     
    Last edited: Dec 19, 2014