Date: Thu, 25 May 2000 18:01:32 -0700 (PDT) From: Kris Kennaway <kris@FreeBSD.org> To: Garance A Drosihn <drosih@rpi.edu> Cc: nsayer@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Needed: suid library calls [or pkey's?] Message-ID: <Pine.BSF.4.21.0005251747240.44741-100000@freefall.freebsd.org> In-Reply-To: <v04210100b55361e29d10@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
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. So you'd have to
realise that allowing a particular process to read/write from a file means
that anyone who can attach a debugger to the process can read/write
however they want, not just using the interface defined in the on-disk
instance of that program.
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).
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).
One of the TrustedBSD design goals is to allow alternative security
policies to be dynamically loaded so that you aren't constrained to e.g.
only use the "POSIX.1e" style of ACL, or whatever policy is hardwired into
FreeBSD.
Kris
----
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <forsythe@alum.mit.edu>
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?Pine.BSF.4.21.0005251747240.44741-100000>