Date: Mon, 7 Sep 1998 19:36:59 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Mike Smith <mike@smith.net.au> Cc: freebsd-current@FreeBSD.ORG Subject: Re: lkm hooks for passing (blah) via file descriptors Message-ID: <Pine.BSF.3.96.980907192025.11972B-100000@fledge.watson.org> In-Reply-To: <199809070539.WAA11569@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 6 Sep 1998, Mike Smith wrote: > Having this submitted as a PR would be very handy. If you could > summarise the effects of "cleaning up a little" in the PR docco, that > would help make a case for this. Mike, I have submitted the patches along with some discussion as PR kern/7856. > > 2. Adding a p_auth pointer in the proc structure (zero'd at fork for the > > new process, although at_fork() lkm's can modify it immediately after the > > fork, and based on the parent value) for hooking arbitrary authentication > > or authorization information into the proc structure. > > Do you have a standard mechanism for chaining items off this pointer, > or do you envisage only ever having one consumer at a time? How about > a generalised interface that puts the current credentials there as well? My current minimalist patches (PR kern/7837) only provide a single pointer (proc.p_authext). However, allowing multiple consumers is a goal I had considered for the patches. If you think this would be more useful (it sounds more useful), I can go ahead and pull something together. The current patches make no changes to the existing credential structure of FreeBSD. > > Would any of these patches be of interest for 3.0-CURRENT? The first > > patch is something that I find useful, but that might not be so useful for > > others. The second might be of more general use; especially if we stick > > want to stick in posix capabilities via an optional lkm (a likely first > > implementation -- I am ordering posix .6 this afternoon). > > I think that the lack of commentary here would tend to indicate that > nobody violently objects, but perhaps that not enough people understand > the ramifications of your changes. If you could paint them in the > context of the kernel-wide authentication infrastructure you described > earlier, in a fashion suitable for consumption by TV-age minds, you > might raise some more noise. > > Basically, the suggestions both seem sound. The greatest concern which > might be raised against the second patch would be that it's perhaps not > being made in the context of a larger and more coherent vision for > authentication management. A number of authentication/authorization projects might be able to take advantage of hooks in the proc structure; here are a few examples that come to mind: Posix Capabilities POSIX 1003.1e defines a set of capabilities that processes may gain through file system flags. Examples of such capabilities might include the privilege to bind a low port number, set the system time, etc. This additional information needs to be stored associated with the process. In the long term, changes to support POSIX capabilities would best be stored off of a more general credential mechanism; in the short term, a hook in the proc structure provides a useful tool. Sandbox Processes An idea that has been bounced around a bit in a few forums I have observed (and has been specifically described by Garrett Wollman) is that of a sandbox syscall. A process could define a set of syscall limitations for itself (or children) that prevent access to specific syscalls. A blunt sandbox definition might just be a list of syscalls that were explicitely denied (fork(),exec(),mmap()). A more sophisticated mechanism might include a defined policy language involving syscall arguments (perhaps in the form of the TIS Wrappers project -- http://www.nai.com/products/security/tis_research/indes.asp). Such a mechanism, if loaded as an lkm, would benefit from a location where it could store process-specific information. FreeBSD Tokens This project is intended to suplement or replace the existing credentials system in a BSD-style kernel. Associated with each process (or group of processes) are a set of 'tokens' that describe rights, identity, etc. Some of these tokens are provided by the user process, others are provided by the kernel or exchanged between processes (using the lkm hooks in the ancillary data patches). A description of some of the ideas behind kernel tokens can be found at http://www.watson.org/fbsd-hardening/tokens/. The latest version that supports token passing between processes via unix domain sockets, and a token daemon is not yet available, but should be in a few days (perhaps Thursday?). The goal of tokens is to allow finer-grained access control, avoid the somewhat restrictive nature of assign users 'uid's, as well as provide a useful security context for network authentication tokens (such as keying material for IPsec, public/private keys, kerberos tickets, AFS/Coda tokens, etc). I am currently writing or planning to write LKMs providing all of these services; there are also a number of other security-related projects under FreeBSD that could make use of these hooks and pointers. I agree that a more general solution than one pointer in the proc structure might be useful. What sort of registration mechanism did you have in mind? On idea I had had involved allocating each interested lkm (or other kernel entity) an authentication type (int). When interested in its pointer, the lkm or process could provide a proc pointer and its registration number and get back its pointer (and similarly modify). Each lkm would express interest in such a number through a registration process, and the number would be assigned. LKMs on unloading could also have the pointers cleaned up for them (although the structures are, of course, the LKMs responsibility). A simple implementation would involve a linked list of registration records off of the proc structure. A more optimized implementation could be written if the number of consumers was sufficiently high to justify it. If this sounds reasonable, I would be glad to go ahead an implement it. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" 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.980907192025.11972B-100000>