Characteristics of a true "default-deny" desktop OS

Discussion in 'all things UNIX' started by Gullible Jones, Mar 24, 2014.

Thread Status:
Not open for further replies.
  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,459
    As in, "implements default-deny policies on all applicable levels of its design while still being usable." What would it look like, and could it be source-compatible with modern Linux or BSD versions?

    Would something like the following work?

    ...

    User accounts: every graphical program with a corresponding .desktop file must run in a limited account separate from the invoking user, but also corresponding to that user. (e.g. if philb runs Firefox, it must run as philb_firefox.) Each user must have full read/write access to these "sub-accounts", and to no other sub-accounts than their own; each sub-account must be completely isolated from the others, and must not be able to modify its default umask.

    GUI: Some kind of centralized clipboard arbitrator, to allow greater isolation between programs using the display server? (Don't know if that could work.)

    Access control: RBAC, i.e. root privileges are split up into several independent roles. (GrSecurity has this already.) Users or groups may be allowed to invoke specific roles, in specific ways if necessary. (e.g. philb may mount /dev/sd* somewhere in his home directory; but not anywhere else, not with dev, suid, or exec options, and not if the volume is already mounted by another user. The BSDs sorta kinda do this with usermount, but IIRC not in a very secure fashion. And yes, this would eliminate the need for HAL/DeviceKit/udisks/pmount et crap.)

    More access control: chmod operations would be privileged and require access to a role.

    ...

    Does any of this sound workable? Am I reinventing some already-existing concept here?
     
  2. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    You can get pretty arbitrarily strict in terms of access control. But at some point you're either putting tons of pressure on the developer (create a profile for your program that tells everyone exactly what it needs) or on the user (does program need X? *popup* does program need Y? *popup*).

    Look at ELFBac.
     
  3. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,459
    Good point, I hadn't thought of access control on the level of program internals. That sounds perhaps a little too fine-grained to be practical. Interesting project though.
     
  4. Mrkvonic

    Mrkvonic Linux Systems Expert

    Joined:
    May 9, 2005
    Posts:
    8,695
    What are you trying to solve?
    Mrk
     
  5. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    ELFBac works off of the implied permissions that programming languages already use.

    Is that member private? Code shouldn't be run from there when called outside of the class, etc.
     
  6. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,459
    @Mrk: none (yet). I'm just (somewhat obsessively) interested in the theoretical aspects of OS security. This stuff has no bearing on my desktop configuration.

    Does it matter? This is a security forum, and security involves more than just user behavior (even if that's currently the most important part of the equation). Theoretical stuff may not be relevant now, but it might be relevant some time down the road.

    @Hungry Man: IOW it enforces OOP style encapsulation as a security mechanism? That is way cool actually.
     
  7. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Yes, it's very cool. Very powerful.
     
  8. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,459
    I'm curious, have you done any pentesting on it? Anything in particular it's good at preventing?

    Also, how much does the internal design/code quality of a program impact its effictiveness from what you know or have seen?
     
  9. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    No, I've never worked with it at all.

    But since the policies are generated based on the semantics of the program, so if everything is just some public structure that can be written and read by every other function it won't help. But that's not how most people write code.

    It can prevent tons of different vulnerabilities, the ELFBac paper would put it better than I could though.
     
  10. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,459
    Hmm. Perhaps I will do some pentesting with elfbac vs. normal kernels when I have the time.

    (The problem is finding vulnerabilities that can actually work in the first place. Metasploit has next to nothing for most current desktop Linuxes.)
     
  11. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    It would most certainly break things.

    Finding vulnerabilities for Linux distros is a pain because Linux has had ASLR for ages and no consistently reliable bypasses, whereas Windows has had the same bypasses for *years* before Windows 8, and XP vulns are classic.
     
Loading...
Thread Status:
Not open for further replies.