Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 May 2000 13:43:23 -0400
From:      Garance A Drosihn <drosih@rpi.edu>
To:        Kris Kennaway <kris@FreeBSD.ORG>
Cc:        nsayer@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Needed: suid library calls [or pkey's?]
Message-ID:  <v04210101b554658ea15b@[128.113.24.47]>
In-Reply-To:  <Pine.BSF.4.21.0005251747240.44741-100000@freefall.freebsd.org>
References:  <Pine.BSF.4.21.0005251747240.44741-100000@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
At 6:01 PM -0700 5/25/00, Kris Kennaway wrote:
>On Thu, 25 May 2000, Garance A Drosihn wrote:
>
> > It was called program keys, or 'pkey's.  When a program
> > was running, there was this pkey attribute (in addition
> > to uid and gid).  The pkey was a 16-character value (if
> > I remember right).  Each executable had a pkey associated
> > with it, and that value became the current pkey when the
> > program started to execute.  Users could change the pkey
>
>There's an inherent security weakness to beware of in this
>system under UNIX: (non-set[ug]id) processes are inherently
>untrustable things - for example you can attach to the
>running program with a debugger and make it run your own
>code no matter what was already there. [...]

Indeed.  The same was true on the OS this comes from.  I was
worried my message was getting too long, so I skipped over
some of the details that come up when implementing this.

>The alternative is to prevent attaching debuggers to any
>process which runs with one of these extended credentials,
>like we do for set[ug]id binaries (this is probably the
>sensible solution).

That's basically how we handled it.

>Such a system could probably be implemented fairly easily
>within the framework of the "extended attributes"/ACL system
>already in FreeBSD along with what's being developed for
>TrustedBSD. Specifically, you'd store a credential ("pkey")
>as an extended attribute on a binary, and have an ACL system
>which knows about these credentials as well as whatever other
>access policies you want (POSIX.1e ACLs, traditional UNIX file
>permissions, etc).

When I wrote my message, I really was just wandering down
memory lane to talk about a feature I missed from my earlier
systems-programming days.  The more I think about it, the more
it sounds like this is something which really COULD be done
for FreeBSD (at least as an option).  I'll have to think about
this some more, as it really would be nice to have this.  I
guess I first have to learn more about the extended-attributes/
ACL system in freebsd or TrustedBSD...

(so many projects, so little time...)


---
Garance Alistair Drosehn           =   gad@eclipse.acs.rpi.edu
Senior Systems Programmer          or  drosih@rpi.edu
Rensselaer Polytechnic Institute


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v04210101b554658ea15b>