Re: Good news for SPARC

From: Frank Cusack (fcusack_at_fcusack.com)
Date: 11/05/03 

Date: Wed, 05 Nov 2003 00:32:39 -0800

On 04 Nov 2003 12:05:33 GMT Casper H.S. *** <Casper.***@Sun.COM> wrote:
> Ah, but the risk there is really only about bugs in applications as
> RBAC does allow for fine grained permission.

That is absolutely correct, but not quite my point. Because RBAC on
unix grants you the ability to run specific user applications, it
is flawed. If you can trick RBAC or if you can find a userland bug
or simple RBAC misconfiguration then RBAC does not limit the user.

Let's consider sudo. Forgive my poor chart.

- setuid exec
  - I'm root. FULL PRIVS.
    - sudo bug? -> full privs compromise
  - Can user run this app?
    - Yes. bug,exploit,misconfig -> full privs compromise

Whereas I understood that some other poster was talking about limited
KERNEL privileges ala capabilities in some other OS. In which case a
bug in userland does not expose the all-or-nothing problem of unix.

>>Linux' kernel capabilities are interesting.
>
> Similar mechanisms have been implemented in many Unix variants.

Yeah, sorry. I didn't mean to imply that Linux had any kind of
superiority or even that kernel capabilities were "original" to Linux.
Just that the capabilities are easy to use with a setuid wrapper.
(And even then, I'm not implying other OS's don't have easy to use
facilities.)

On 04 Nov 2003 12:13:57 GMT Casper H.S. *** <Casper.***@Sun.COM> wrote:
> Ah; I see where you are going. I don't think that "vi" is a valid
> counter argument for "RBAC";

Yes, it wasn't an ideal example. I just meant that, any application
granted via RBAC doesn't just grant *that* application, it grants
FULL PRIVILEGES (ok, assume root here even though in the general
case that's not true) and then whatever happens in that app can happen,
with full privileges. It's not like a kernel priv limiting mechanism
like ACLs where access to some file doesn't give access to all other
parts of the system.

>>ACLs are really really close to being ideal. The problem is that not
>>everything is a file in unix. (cue plan9)

I take that back. Even if everything were a file, ACLs wouldn't allow
you to write some values but not others, etc.

> Well, pick a better example than "vi"; we're agreed that you can't assign
> "vi + root" safely to a user; but let's also agree that
> "vi + fine grained privileges" doesn't work either.

Yes, I agree.

> Adding an ACL to "Everything is a file" isn't sufficient either;
> in some cases you'd want to have a privileged process in control of
> updating a system file/database/what not in a restricted fashion depending
> on the authorizations assigned to a specific user.

Yep.

>>There are tools that allow finer grained permissions, eg SeOS. (which
>>is now defunct, AFAICT). It works (worked) by intercepting syscalls
>>and allowing or denying specific operations. Not as good as being
>>directly in the kernel, but close. (google for [memco seos])
>
> Trusted Solaris provides close to the same capabilities and more.

Oh, I didn't know that. I'll have to check it out.

The OpenBSD systrace someone else mentioned sounds very interesting as well.

/fc

Quantcast