Date: Mon, 20 Sep 1999 11:48:23 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Kiril Mitev <kiril@ideaglobal.com> Cc: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, ark@eltex.ru, security@FreeBSD.ORG Subject: Access Control (was: Re: Real-time alarms) Message-ID: <Pine.BSF.3.96.990920113451.42321C-100000@fledge.watson.org> In-Reply-To: <199909201507.PAA30804@loki.ideaglobal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Sep 1999, Kiril Mitev wrote: > Ouch. > > do you REALLY suggest things along the lines > > set proc/priv=(... , .... , .... ) ... > > > 2) acl device that will provide 2-way communication to a daemon that will > > > allow or deny things to happen? > > > > This is no longer auditing, that would be under another thread, one about > > security control, and goes hand in hand with the proposal I tossed out > > about VMS like per process priviledges. POSIX.1e describes a set of capabilities + interface, which the Linux people have already implemented (with extensions to make it useful). I am not convinced that the approach selected in POSIX.1e is the correct approach--the lack of extensibility for capabilities looks pretty limiting. On the other hand, it should be recognized that the advantages of a portable capability scheme would be many, and that POSIX.1e evolved out of a body of authors who wrote *many* trusted operating systems. A couple of years ago I implemented an extension to FreeBSD to bind a set of "tokens" to pools of process authentication/authorization groups--tokens represented kernel capabilities, kernel authentication information, as well as keying material provided by user processes. I extended a number of syscalls to make use of capability tokens with specific names, and provided some primitives for creating and managing the tokens. Central to this approach as the idea of transfering tokens, and having tokens that the kernel could protect against duplication, unauthorized transfer, etc. I provided a primitive allowing processes to share tokens via unix domain sockets, and had a tokend that accepted requests for exchanges of tokens: a typical login sequence went something like this: login, running effectively unauthorized, is spawned. It requests authentication information from the user (username, password) and creates a token containing this information. It connects to /var/run/token (a unix domain socket) and transfers to token to the socket, along with a request for authentication to the username account. Tokend, based on a policy file, would allow the exchanges of specific types of tokens for other tokens--for example, a valid username/password token for a set of UNIX uid and gid tokens representing a traditional user credential set. I similarly allowed the exchange of kerberos tickets, represented as tokens, for user credentials. I also allowed the exchange of such tokens for specific capability tokens--such as binding of specific port numbers in specific ways, etc. Processes requiring additional privilege could request it via the socket and ancillary token transfer. While I'm not suggesting this is the correct long-term solution, it does make use of what I feel are a few extremely useful features of a capability system. These include flexibility (a string-based capability model allowing things like socket/bind/ip/tcp/25), mechanism for acquiring new privileges without necessarily using a traditional unix "you execute something to get'em" setuid style, ways to limit their spread (the kernel could prevent the transfer of tokens marked as limited), and the ability to describe existing concepts in UNIX (uids/etc). Also, the ability to have a configurable policy in a file somewhere, managed in a central manner by a single code base (tokend) without bloating the kernel. A configurable policy is something I feel is extremely important so that we can make new security features accessible (and acceptable) to those with varying security needs. Extending the file system to support capabilities is something that has held up the Linux crowd--while they have implemented what they need in terms of access control and process capability management, they haven't gotten the capabilities into the base FS. Avoiding file-system based capabilities seems like an easier solution: no need to newfs, extend file system interfaces, deal with problems when it comes to distributed file systems, etc. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" 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.3.96.990920113451.42321C-100000>