From owner-freebsd-arch Fri Jan 29 04:35:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA10807 for freebsd-arch-outgoing; Fri, 29 Jan 1999 04:35:04 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA10762 for ; Fri, 29 Jan 1999 04:35:00 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id NAA11166 for ; Fri, 29 Jan 1999 13:34:57 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA35398 for freebsd-arch@freebsd.org; Fri, 29 Jan 1999 13:34:57 +0100 (MET) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA04676; Fri, 29 Jan 1999 03:49:40 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id MAA05345; Fri, 29 Jan 1999 12:49:34 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA35165; Fri, 29 Jan 1999 12:49:33 +0100 (MET) Date: Fri, 29 Jan 1999 12:49:33 +0100 From: Eivind Eklund To: arch@FreeBSD.ORG Subject: Re: "JAIL" code headed for -current. Message-ID: <19990129124932.A34859@bitbox.follo.net> References: <29763.917434096.kithrup.freebsd.current@critter.freebsd.dk> <199901271944.LAA15317@kithrup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199901271944.LAA15317@kithrup.com>; from Sean Eric Fagan on Wed, Jan 27, 1999 at 11:44:35AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm moving this to FreeBSD-arch, due to taking the discussion quite a bit in that direction. On Wed, Jan 27, 1999 at 11:44:35AM -0800, Sean Eric Fagan wrote: > In article > <29763.917434096.kithrup.freebsd.current@critter.freebsd.dk> you > write: > >The biggest impact of this is a new argument to the suser() call > >all over the kernel: > > > > suser(NOJAIL, bla, bla); > >or > > suser(0, bla, bla); > > Oh, goody, more gratuitous incompatibilities with everyone else. suser() is not generally compatible; the return value has different (opposite) meanings in different OSes. I do, however, think there are a couple of problems with the implementation as outlined above, even if we ignore any incompatibility arguments: 1. It is insecure in the face of changes. Any security policy should default to deny; the above policy default to 'accept'. Later kernel mods are likely to introduce security holes. 2. If more similar authentication mods are made, they also require changes all over the system. 3. Policy is distributed everywhere, instead of a being concentrated in one place, which makes it hard to verify. I have been planning some changes for much of the same purpose. My approach is to introduce a string identifying each context for suser(), to allow people that want to hack on the authentication system an easy place to start from. In a similar setting before, I've successfully used a hierarchical system, going from less to more specific context specification. Example: a chflags in an FFS would be something like "fs/chflag/ufs/ffs" while in an lfs, it would be "fs/chflag/ufs/lfs". I've not thought much about the backend for this - if it is to be used in general (instead of just as a good starting point for people that want to do some authentication hacks on their machine), there should probably be some way to express interest in just some of the nodes of the tree the different authentication types form, and caching to avoid string parsing. If phk would be satisfied with a slightly hackish solution for the time being, we could introduce the above, and just use string compares for his acceptable cases for the time being. This could be done as a binary tree, so it wouldn't be quite as expensive as it sounds. Context for the people not having done their own source investigation of credentials use: We have approx 180 root checks using suser(): eivind(bitbox)--% glimpse -y suser | wc -l 185 We have approx 90 checks for root that are NOT done using suser(), rather using explicit comparisons with 0: eivind(bitbox)--% glimpse -y cr_uid | grep 0 | wc -l 94 Another interesting statistic for root mods probably is the number of cr_uid references in the kernel (all of these should be inspected): eivind(bitbox)--% glimpse -y cr_uid | wc -l 283 If you're thinking of a full-blown look at capabilities, cr_gid is used 28 places, cr_groups 60, and cr_ngroups 52. Given the relatively low number of credentials uses (less than 400), it shouldn't be more than a couple of evenings worth of work to collapse it all back to a set of function or macro calls, creating a much more suitable environment for capabilities hacking. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 29 12:06:50 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA04482 for freebsd-arch-outgoing; Fri, 29 Jan 1999 12:06:50 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA04469 for ; Fri, 29 Jan 1999 12:06:44 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id VAA25958 for ; Fri, 29 Jan 1999 21:06:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA37755 for freebsd-arch@freebsd.org; Fri, 29 Jan 1999 21:06:36 +0100 (MET) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA23242 for ; Fri, 29 Jan 1999 10:38:13 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id TAA24944 for ; Fri, 29 Jan 1999 19:38:10 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA37398 for arch@FreeBSD.ORG; Fri, 29 Jan 1999 19:38:10 +0100 (MET) Date: Fri, 29 Jan 1999 19:38:09 +0100 From: Eivind Eklund To: arch@FreeBSD.ORG Subject: Re: "JAIL" code headed for -current. Message-ID: <19990129193809.H34859@bitbox.follo.net> References: <29763.917434096.kithrup.freebsd.current@critter.freebsd.dk> <199901271944.LAA15317@kithrup.com> <19990129124932.A34859@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19990129124932.A34859@bitbox.follo.net>; from Eivind Eklund on Fri, Jan 29, 1999 at 12:49:33PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 29, 1999 at 12:49:33PM +0100, Eivind Eklund wrote: > I have been planning some changes for much of the same purpose. My > approach is to introduce a string identifying each context for suser(), > to allow people that want to hack on the authentication system an easy > place to start from. Eh - to expand somewhat (I forgot to include some significant parts): I was planning on adding both a string (hierarchical, to indicate placement in a tree), and a context-dependent extra void* parameter. This could e.g. be used to transfer the particular port a user is attempting to open. Note that this turn the strings passed to suser() into a type hierarchy (normal object-oriented inheritance) for the void* parameter. With the ANSI C requirement that any two structs that start with the same set of types (ie, have the same types of a number of members, starting from the first in the struct) should have the same memory layout, it should be possible to use standard C structures and just add members at the end (barring Bruce's mythical C compiler that tag types on structure pointers). To take the previous example with "fs/chflag/ufs/ffs" and "fs/chflag/ufs/lfs", we could have a struct authdata_fs_chflag_ufs { int somedata; char *otherdata; }; which has the data required for fs/chflag/ufs, and then struct authdata_fs_chflag_ufs_ffs { int somedata; char *otherdata; long ffs_specific_data; }; struct authdata_fs_chflag_ufs_lfs { int somedata; char *otherdata; struct mumbojumbo *lfs_specific_data; struct othermumbo *more_lfs_specific_data; }; with specific data for each of ffs and lfs, for this particular operation. Of course, the base setup (before we define all the data-formats etc) would be to just pass NULL. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message