Characteristics of a true "default-deny" desktop OS

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?

 

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.

 

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.

 

What are you trying to solve?
Mrk

 

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.

 

@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.

 

Yes, it's very cool. Very powerful.

 

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?

 

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.

 

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.)

 

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.