From owner-freebsd-hackers Thu May 25 18: 1:35 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 2760B37B581; Thu, 25 May 2000 18:01:33 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id SAA47659; Thu, 25 May 2000 18:01:32 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Thu, 25 May 2000 18:01:32 -0700 (PDT) From: Kris Kennaway To: Garance A Drosihn Cc: nsayer@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Needed: suid library calls [or pkey's?] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message