From owner-lomac-users Wed May 10 10:56:38 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14105 Wed, 10 May 2000 10:55:51 -0400 (EDT) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Wed, 10 May 2000 11:12:04 -0400 (EDT) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: lomac-users@lists.tislabs.com Subject: LOMAC 0.3pre1 pre-release on FTP site Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! LOMAC 0.3pre1 is available via anonymous FTP at: ftp://ftp.tislabs.com/pub/lomac/lomac-v0.3pre1.tar.gz I'll append the release notes to this message. In other news, I'll be presenting a paper "LOMAC: Low Water-Mark Integrity Protection for COTS Environments" at the 2000 IEEE Symposium on Security and Privacy in Oakland, California, USA, on Wednesday 17 May. This paper explains LOMAC's compatibility goals, argues that models like Low Water-Mark are good for compatibility, and describes LOMAC's techniques for avoiding the well-known problems with the model during run-time. The high point of the conference, however, will most likely be the panel discussion of the question "Does open source really improve system security?" ESR will be one of the panelists; it should be a lively event. - Tim --- This is the LOMAC 0.3pre1 pre-release. This pre-release of LOMAC exists only to demonstrate the key implementation strategies that will (hopefully) eventually lead to LOMAC 0.3. If all goes well, LOMAC 0.3 will be a significantly smaller, simpler, and more functional release than 0.2. Those adventurous enough to have loaded LOMAC 0.2 on their machines may have discovered that it had a tremendous appetite for kernel memory. Even on an idle machine, it would eventually (within a day) allocate all available kernel memory, effectively preventing the OS from doing any useful work. This appetite stemmed from the 0.2 prototype's need to maintain dynamically allocated shadow data structures that mapped security attributes to task_structs and inodes. The LOMAC allocation code worked very well; the deallocation code, on the other hand, didn't. Faced with this problem, I decided to follow Fred Brooks' advice from his famous "Mythical Man Month" book, threw out LOMAC 0.2, and started fresh on a 0.3 prototype. The new prototype maps attributes to kernel data structures by shoehorning the attribute data into the unused bits of the existing structures. Since the LOMAC attributes reside in the existing kernel structures, LOMAC does not need to keep any shadow data structures of its own. Consequently, the 0.3 prototype performs no dynamic memory allocation, and is considerably smaller and simpler. (The old FSOLM, VLM, and vnode interface were on the order of 300 lines of code. The 0.3pre1 prototype seems to do the same job with about half that many lines.) The 0.3pre1 pre-release also demonstrates a new method of mapping levels onto objects in the filesystem (see lomac_plm.[ch] - no more gid hack). If this new method works out, it will provide a simple mapping scheme that is persistent across reboots. The 0.3pre1 pre-release implements no useful LOMAC functionality - it just demonstrates some of the new code by filling your log with diagnostic messages. Hopefully, more functionality will be coming along soon. This version of LOMAC supports only single-CPU systems running Linux 2.2 kernels. From owner-lomac-users Mon Jun 19 12:54:34 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21524 Mon, 19 Jun 2000 12:53:35 -0400 (EDT) Date: Mon, 19 Jun 2000 12:59:55 -0400 (EDT) From: Timothy Fraser X-Sender: tfraser@clipper.gw.tislabs.com Reply-To: Timothy Fraser To: lomac-users@lists.tislabs.com cc: tfraser@tislabs.com Subject: LOMAC 0.3pre2 on FTP site Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! LOMAC 0.3pre2 is available via anonymous FTP at: ftp://ftp.tislabs.com/pub/lomac/lomac-v0.3pre2.tar.gz I'll append the release notes to this message. This release also contains the 2000 S&P Symposium LOMAC paper in PDF format. - Tim This is the second pre-relase in the series leading up to LOMAC 0.3. LOMAC 0.3 is intended to be smaller, simpler, and more functional that the earlier 0.2 release. Like the pre1 pre-release, this pre-release implements no useful access control functionality - it just demonstrates some of the new code by filling the system log with diagnostic messages. The following new functionality has been added: o A better-organized logging facility. o Monitoring of reads on files and network sockets. o Proper subject demotion behavior. o Logging of illegal writes to files (no accesses are denied as of yet). o An interface to provide information to the user-space lps and lls scripts, and the scripts themselves. This version of LOMAC supports only single-CPU systems running Linux 2.2 kernels. It compiles on the x86 architecture, but not on the Alpha architecture (the makefile needs tweaking, I think.) Note that it's hard to get a level-2 login session with the policy that's hard-coded into the current version of the prototype. It sets the contents of the /var directory to level-1. The login program likes to read files like /var/log/lastlog, demoting it (and the user sessions it spawns) to run at level-1. A better policy is on the things-to-do list for the next pre-release. From owner-lomac-users Fri Jun 30 11:46:16 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13093 Fri, 30 Jun 2000 11:46:06 -0400 (EDT) Date: Fri, 30 Jun 2000 11:51:27 -0400 (EDT) From: Timothy Fraser X-Sender: tfraser@clipper.gw.tislabs.com To: lomac-users@lists.tislabs.com cc: tfraser@tislabs.com Subject: LOMAC v0.3pre3 on FTP site Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! LOMAC v0.3pre3 is available on via FTP at: ftp://ftp.tislabs.com/pub/lomac/lomac-v0.3pre3.tar.gz I'll append the release notes below. - Tim This is the third pre-relase in the series leading up to LOMAC 0.3. LOMAC 0.3 is intended to be smaller, simpler, and more functional that the earlier 0.2 release. Like the pre1 and pre2 pre-releases, this pre-release implements no useful access control functionality - it just demonstrates some of the new code by filling the system log with diagnostic messages. The following new functionality has been added: o An improved means of assigning levels to objects in the filesystem. The old mechanism was capable of expressing relationships like: "/home and everything under it is level 2." The new mechanism is capable of expressing more complex relationships like: "/home is level 2. /home/httpd is level 2. All else under /home is level 1." (The "all else" is the new bit). o Constraints on the use of unnamed pipes as described in the LOMAC paper in the doc section of the distribution (logging only, no access denials as of yet). This version of LOMAC supports only single-CPU systems running Linux 2.2 kernels. It compiles on the x86 architecture, but not on the Alpha architecture (the makefile needs tweaking, I think.) t on the Alpha architecture (the makefile needs tweaking, I think.) From owner-lomac-users Mon Aug 7 11:22:53 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28726 Mon, 7 Aug 2000 11:22:23 -0400 (EDT) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Mon, 7 Aug 2000 11:44:34 -0400 (EDT) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: lomac-users@lists.tislabs.com Subject: SACMAT 2001 CFP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! SACMAT 2001 (6th ACM Symposium on Access Control Models and Technologies) has put out their call for papers. Here's some more info for anyone who might be interested in submitting a paper or attending: May 3-4, 2001, Chantilly, VA, USA http://www.acm.org/sigsac/sacmat2001.html The official CFP isn't yet up on this page as I write this, but I'll forward a copy to anyone who wants one. An excerpt from the official CFP follows (transcribed in haste by me from the original pdf CFP, any errors are mine): SACMAT 2001 is the successor to the ACM Workshop on Role-Based Access Control in which the organizers aim to provide a meeting place for researchers in all facets of access control, including models, systems, applications, and theory. Historically, access control research has been published in their respective domains or as niche work in general security conferences, but this symposium gives researchers the opportunity to share their perspectives with others interested in access control in particular. Contributions are solicited for areas including, but not limited to: Access control requirements Access control mechanisms Access control models and extensions Safety enforcement Access control applications Access delegation Administration of access policy System evaluation Systems for enforcing access control Distributed authorization Important dates: Submission of papers: November 17, 2000 Panel proposals: November 17, 2000 Notification to authors: January 15, 2001 Camera-ready copies: February 15, 2001 From owner-lomac-users Mon Aug 28 08:59:09 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18190 Mon, 28 Aug 2000 08:58:32 -0400 (EDT) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Mon, 28 Aug 2000 09:09:59 -0400 (EDT) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: lomac-users@lists.tislabs.com cc: tfraser@tislabs.com Subject: LOMAC v0.3pre4 on FTP site In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! LOMAC v0.3pre4 is available on via FTP at: ftp://ftp.tislabs.com/pub/lomac/lomac-v0.3pre4.tar.gz I'll append the release notes below. - Tim This is the fourth pre-release in the series leading up to LOMAC 0.3. LOMAC 0.3 is intended to be smaller, simpler, and more functional that the earlier 0.2 release. Unlike the earlier logging-only LOMAC 0.3 pre-releases, this pre-release is sufficiently functional to provide actual mediation on the open, creat, read, readv, write, writev, mknod (FIFO creation only), truncate, ftruncate, unlink, rename, and link system calls when operating on files, network sockets, unnamed pipes, and FIFOs. Other changes since the 0.3pre3 release include: o A new "floating levels" scheme for constraining the use of unnamed pipes which cures compatibility problems with some common cron jobs. o A function for predicting the canonical absolute form of paths that describe non-existent files (needed to mediate creat's and trunc's). o A collection of scripts to test LOMAC's mediation of the system calls listed above. Although the 0.3pre4 LOMAC prototype does demonstrate some useful integrity protection, it does not yet provide mediation for many significant system calls and object types (most notably the kill call, local-domain sockets, shared memory, and semaphores). Consequently, it cannot defend against a determined attacker, and should be used for experimental purposes only at this time. This version of LOMAC supports only single-CPU x86 systems running Linux 2.2 kernels. From owner-lomac-users Wed Nov 29 12:26:09 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16722 Wed, 29 Nov 2000 12:24:06 -0500 (EST) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Wed, 29 Nov 2000 13:40:25 -0500 (EST) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: lomac-users@lists.tislabs.com cc: tfraser@tislabs.com Subject: LOMAC v0.3pre5 on FTP site Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! LOMAC v0.3pre5 is available on via FTP at: ftp://ftp.tislabs.com/pub/lomac/lomac-v0.3pre5.tar.gz I'll append the release notes below. - Tim This dir contains the source for LOMAC v0.3pre5 for Linux. This is the fifth pre-release in the series leading up to LOMAC 0.3. LOMAC 0.3 is intended to be smaller, simpler, and more functional than the earlier 0.2 release. Changes since the 0.3pre4 release include: o The implementation of a new pipe constraint scheme that uses floating pipe "levels" to accommodate cron jobs that like to use unnamed pipes across job boundaries. o Added code to predict canonical absolute paths based on parameters passed to open and mknod paths. This addition was needed to do real mediation on creat/truncs. o Added mediation/monitoring of FIFOs. o Added mediation for link, unlink, rename, truncate, and ftruncate. o You can now turn mediation on/off with a compile-time flag. o Added a bunch of test scripts. Although the 0.3pre5 LOMAC prototype does demonstrate some useful integrity protection, it does not yet provide mediation for many significant system calls and object types (most notably the kill call, local-domain sockets, and System V IPC). Consequently, it cannot defend against a determined attacker, and should be used for experimental purposes only at this time. This version of LOMAC supports only single-CPU x86 systems running Linux 2.2 kernels. From owner-lomac-users Thu Dec 21 13:22:05 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06767 Thu, 21 Dec 2000 13:21:30 -0500 (EST) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Thu, 21 Dec 2000 14:38:39 -0500 (EST) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: lomac-users@lists.tislabs.com cc: tfraser@tislabs.com Subject: LOMAC v0.3pre6 on FTP site Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! LOMAC v0.3pre6 is available on via FTP at: ftp://ftp.tislabs.com/pub/lomac/lomac-v0.3pre6.tar.gz I'll append the release notes below. - Tim This dir contains the source for LOMAC v0.3pre6 for Linux. This is the sixth pre-release in the series leading up to LOMAC 0.3. LOMAC 0.3 is intended to be smaller, simpler, and more functional than the earlier 0.2 release. Changes since the 0.3pre5 release include: o Added mediation/monitoring of UNIX (local) domain sockets. o Improved default PLM configuration, and included a secondary configuration tailored for laptops that use DHCP. o Fixed ps-output parsing bug in lps. Although the 0.3pre6 LOMAC prototype does demonstrate some useful integrity protection, it does not yet provide mediation for many significant system calls and object types (most notably the kill call and System V IPC). Consequently, it cannot defend against a determined attacker, and should be used for experimental purposes only at this time. This version of LOMAC supports only single-CPU x86 systems running Linux 2.2 kernels. Some notes on the default PLM configuration: The PLM is the "Path-Level Map" - the data structure that maps levels to files in the filesystem namespace. Its default configuration presently has a problem concerning /var/log/lastlog. /sbin/init reads from this file. This fact compels us to set /var/log/lastlog at the high level, since if /sbin/init ever reads a low file, it will be demoted, and will subsequently have insufficient privilege to shut down the machine. However, sessreg - part of the XDM suite of programs for managing X logins - needs /var/log/lastlog to be low so it can write to it at the start of each user session. It seems (after a few minimal tests) that sessreg won't start a session unless it can write to /var/log/lastlog. The present PLM configuration sets /var/log/lastlog high, so if you boot your machine into runlevel 5 (X) and use an XDM configuration that uses sessreg, you will not be able to log in via X. You can rescue yourself by hitting CTRL-ALT-F1 and logging in at a virtual console. If you boot your machine into runlevel 3 (multiuser) and start X manually via "xinit" or "startx", you will not experience this problem. I hope to fix this sessreg problem, soon. As noted above, there is also a secondary PLM configuration for laptops that use DHCP. See the LKM Makefile for instructions on how to use this secondary configuration. It allows local DHCP agents to modify certain network configuration files, such as /etc/resolv.conf. Such modification are not permitted by the default PLM configuration. From owner-lomac-users Thu Dec 21 13:46:04 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06828 Thu, 21 Dec 2000 13:46:03 -0500 (EST) Message-Id: From: HYADUCKJ To: lomac-users@lists.tislabs.com Subject: list Date: Thu, 21 Dec 2000 13:50:08 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk list From owner-lomac-users Fri Dec 29 14:26:56 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28610 Fri, 29 Dec 2000 14:25:06 -0500 (EST) Date: Fri, 29 Dec 2000 14:26:21 -0500 (EST) From: Timothy Fraser X-Sender: tfraser@clipper.gw.tislabs.com To: lomac-users@lists.tislabs.com cc: tfraser@tislabs.com, lee_badger@nai.com, mark_feldman@nai.com Subject: LOMAC v0.3 on FTP site Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! At long last, LOMAC v0.3 is finally available via FTP at: ftp://ftp.tislabs.com/pub/lomac/lomac-v0.3.tar.gz LOMAC v0.3 is a stable reimplementation of LOMAC v0.2, suitable for everyday use. I'll append the release notes below. - Tim This is the main README for LOMAC v0.3 for Linux. LOMAC is an attempt to make an easily-adoptable form of MAC integrity protection available to the Free UNIX community without the discouraging necessity of kernel modifications. LOMAC implements a simple form of MAC integrity protection based on Biba's Low Water-Mark model in a Linux Loadable Kernel Module (LKM). Although it trades off some of the advanced MAC features found in traditional MAC implementations, LOMAC provides useful integrity protection without any modifications to the kernel, applications, or their existing configurations. LOMAC is designed to be compatible with existing software, and ships with a one-size-fits-all default configuration. LOMAC may be used to harden currently-deployed Linux systems simply by loading the LKM into the kernel shortly after boot time. LOMAC is Free software. The latest release is available for download under the GNU GPL at ftp://ftp.tislabs.com/pub/lomac. More detailed information about LOMAC, its use, the protection it provides, and its relation to other Linux MAC projects can be found in the LOMAC Manual, included under the Doc subdirectory of this distribution. In addition, the paper: Fraser, Timothy, "LOMAC: Low Water-Mark Integrity Protection for COTS Environments", Proceedings of the 2000 IEEE Symposium on Security and Privacy, Berkeley, California, pp. 230-245, May, 2000. can be found at ftp://ftp.tislabs.com/pub/lomac/lomac-sp00.pdf. This paper describes LOMAC's compatibility goals and explains why the Low Water-Mark form of MAC is especially suitable for meeting them. This second-generation LOMAC prototype is a clean reimplementation of the first v0.2 prototype providing equivalent functionality with (we believe) fewer bugs. Unlike the first prototype, LOMAC v0.3 is sufficiently robust for everyday use. Presently, two members of the NAI labs staff run it on their Linux workstations at all times. We expect this number to grow. All LOMAC development since v0.3pre5 has been done on machines running LOMAC, as has the preparation of this release tarball, including the creation of this README file. We encourage others to experiment with LOMAC, as well. Although it is sufficiently stable for everyday use, LOMAC v0.3 is not bug-free. Some security-relevant operations are not yet controlled by LOMAC, including reboot, mmap, and all forms of System V IPC. Furthermore, LOMAC contains numerous time-of-check/time-of-use bugs which permit specially-constructed programs to misuse of some of the operations which LOMAC does control. As LOMAC development continues, we expect to address these problems. Nevertheless, we believe that LOMAC presently provides sufficient protection to defend against relatively unskilled attackers who are not capable of adapting their methods to bypass LOMAC. This version of LOMAC supports only single-CPU x86 systems running Linux 2.2 kernels. Changes since the last release (v0.3pre6) include: o Added mediation on signals. o Added trust functionality and an upgrader like cp "lup". o Updated policy to put /var/log/messages high, now that syslogd is trusted. o Added monitoring of the SYS_RECV* calls on UNIX-domain sockets. o "Finalized" the PLM. o Added mediation on mkdir, rmdir, mknod, mount, umount. o Added read monitoring on sys_execve(). o Combined laptop-specific policy with main policy to create single default policy. The "lup" program is LOMAC's trusted upgrade program. Administrators can use it to move a low-level file into the high-level part of the system in exceptional circumstances. From owner-lomac-users Tue Jan 2 16:03:27 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00763 Tue, 2 Jan 2001 16:02:51 -0500 (EST) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Tue, 2 Jan 2001 17:21:10 -0500 (EST) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: lomac-users@lists.tislabs.com cc: tfraser@tislabs.com, lee_badger@nai.com, mark_feldman@nai.com Subject: LOMAC v1.0 on FTP site Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! LOMAC v1.0, the first full release of LOMAC, is now available for download at: ftp://ftp.tislabs.com/pub/lomac/lomac-v1.0.tar.gz This version provides the same functionality as the previous v0.3 release, with a completely revised manual. The manual includes updated instructions for installation and de-installation, along with a short script for a tour of LOMAC's major features. Consequently, trying out this version of LOMAC should be much less painful than trying out the previous releases. I encourage everyone to give it a shot. The manual also includes the result of two performance benchmarks. The first benchmark measured the time to build the Linux kernel with and without LOMAC. On this test, LOMAC caused no reliably measurable loss of performance. The second benchmark measured the maximum number of replies per second httpd could make running on systems with and without LOMAC. This was a harder benchmark, since the pages being served were very small, and there was little computation and I/O time to mask the time spent on LOMAC's operation. The results showed that the httpd server peaked near 134 replies/second without LOMAC, and 127 replies/second with. This result translates to an approximately 5% performance penalty due to the use of LOMAC... not too bad for a release without any performance optimizations. - Tim From owner-lomac-users Tue Jan 9 14:02:13 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22345 Tue, 9 Jan 2001 14:01:22 -0500 (EST) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Tue, 9 Jan 2001 15:19:56 -0500 (EST) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: lomac-users@lists.tislabs.com cc: tfraser@tislabs.com, mark_feldman@nai.com, lee_badger@nai.com Subject: LOMAC v1.0.1 on FTP site Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! LOMAC v1.0.1 is now available for download at: ftp://ftp.tislabs.com/pub/lomac/lomac-v1.0.1.tar.gz This version fixes a dentry reference-counting bug reported by debut at swbell.net. When handling BIND operations, LOMAC would increment the reference count on socket dentries without decrementing. As a result, port would remain bound even after applications closed all their sockets. This version also makes a few corrections to the performance section of the manual, as suggested by mark_feldman@nai.com. He pointed out that the kernel-build benchmark numbers were good measurements after all - I had misinterpreted the meaning of the standard deviation numbers. - Tim From owner-lomac-users Wed Jan 10 16:56:27 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29165 Wed, 10 Jan 2001 16:56:07 -0500 (EST) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Wed, 10 Jan 2001 18:14:08 -0500 (EST) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: lomac-users@lists.tislabs.com Subject: FYI - LOMAC pgrp/level bug Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! lee_badger at nai.com has reported another bug in LOMAC. The bug is described in the BUGS file: LOMAC doesn't keep members of a pgrp at the same level. I thought this bug wouldn't lead to problems, but one of my PANIC statements caught it on his machine: Jan 10 16:10:34 yoga kernel: LOMAC/K: found invalid level for D0d0i1311 Jan 10 16:10:34 yoga kernel: LOMAC/K: found invalid level for D0d0i1310 Jan 10 16:10:34 yoga kernel: LOMAC/K: attempted to set invalid level for p1059g1 059<0>Kernel panic: LOMAC/K: set_subject_level not consistent across pgrp I'll send out a fix for this as soon as I can. - Tim From owner-lomac-users Mon Jan 22 16:13:00 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19880 Mon, 22 Jan 2001 16:10:49 -0500 (EST) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Mon, 22 Jan 2001 17:30:09 -0500 (EST) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: lomac-users@lists.tislabs.com cc: tfraser@tislabs.com, mark_feldman@NAI.com, lee_badger@NAI.com Subject: LOMAC v1.0.2 on FTP site Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! LOMAC v1.0.2 is now available for download at: ftp://ftp.tislabs.com/pub/lomac/lomac-v1.0.2.tar.gz Changes in LOMAC v1.0.2: o Tweaked the PLM to make /mnt/cdrom and /mnt/floppy level-2, but all other children of /mnt low. This change allows level-1 users to access filesystems NFS-mounted under /mnt. As reported by lee_badger at nai.com, before this change, write access to NFS-mounted filesystems was effectively impossible. LOMAC prevented level-1 users from writing to the level-2 mounted files. Although LOMAC would permit writes from level-2 users, LOMAC's default policy effectively permits only the root user to operate at level-2, and the existing NFS access control mechanisms are generally configured to prevent root writes. o Added a description of the related SubDomain project to the LOMAC manual. o Changed a printk to a PANIC in kernel_interface.c:set_subject_level(). - Tim From owner-lomac-users Wed Feb 7 15:26:00 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00891 Wed, 7 Feb 2001 15:25:29 -0500 (EST) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Wed, 7 Feb 2001 16:45:35 -0500 (EST) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: lomac-users@lists.tislabs.com cc: mark_feldman@NAI.com, lee_badger@NAI.com, tfraser@tislabs.com Subject: LOMAC v1.0.3 on FTP site In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! LOMAC v1.0.3 is now available for download at: ftp://ftp.tislabs.com/pub/lomac/lomac-v1.0.3.tar.gz Changes in LOMAC v1.0.3: o I finally fixed the unnamed IPC object bug that Lee Badger found when he ran "xscreensaver-command -lock". It turned out that LOMAC was not assigning levels to UNIX-domain sockets in two cases: (1) when the sockets were created with sys_socketpair, and (2) when the sockets were bound to names in the abstract namespace. These problems are now fixed, although the solution may be sub-optimal. LOMAC now gives UNIX domain sockets created with socketpair the same level as the process that created them. This works, but in the future, we may want a better solution based on the way LOMAC currently handles unnamed pipes. LOMAC now assigns all UNIX domain sockets bound to names in the abstract namespace to LOMAC_LOWEST_LEVEL (1). This simple solution works, but it prevents high-level processes from making use of UNIX domain sockets bound to abstract names without being demoted. A better solution for this may be needed someday, as well. o I shortened the TPL - the list of trusted programs. I removed initlog and klogd - they didn't need to be trusted after all. o Added a description of the Pitbull LX project to the LOMAC manual. - Tim From owner-lomac-users Tue Feb 13 14:46:14 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23799 Tue, 13 Feb 2001 14:44:31 -0500 (EST) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Tue, 13 Feb 2001 14:46:21 -0500 (EST) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: lomac-users@lists.tislabs.com cc: mark_feldman@NAI.com, lee_badger@NAI.com, tfraser@tislabs.com Subject: LOMAC v1.0.4 on FTP site Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! LOMAC v1.0.4 is now available for download at: ftp://ftp.tislabs.com/pub/lomac/lomac-v1.0.4.tar.gz Changes in LOMAC v1.0.4: o Improved performance of lps and lls scripts by moving the functionality of the linfo and level scripts into a Perl module. Many thanks to John Thiltges who submitted the code to solve this problem. o Updated manual to reflect the above fix. The LKM is unchanged except for a version-number increment. The improvements are all in the scripts under Src/Scripts. With LOMAC running, you can upgrade most easily by tarring up the Scripts directory, and then using /opt/lomac/bin/lup to upgrade the tar file to level 2. Once it's at level 2, LOMAC will allow you to untar the new scripts into /opt/lomac/bin. Alternately, you can turn LOMAC off by doing /sbin/chkconfig --del lomac and rebooting. After installing the new scripts you can /sbin/chkconfig --add lomac and reboot again to turn LOMAC back on. - Tim From owner-lomac-users Mon Feb 19 14:07:41 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17239 Mon, 19 Feb 2001 14:07:10 -0500 (EST) Message-ID: <3A916F86.226576E3@alaska.net> Date: Mon, 19 Feb 2001 10:09:58 -0900 From: James Zuelow Organization: Not really X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: lomac-users@lists.tislabs.com Subject: Debian 2.2 sock.h Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hello, I have a Debian 2.2 firewall (Potato, apt-get dist-upgrade every week or so). I don't normally keep a compiler on my firewall box, but wanted to install Lomac. So this morning I did an apt-get install task-debian-devel to put gcc etc. on the box. I untarred lomac-v1.0.4 into /usr/local/Lomac, and edited the Makefile in Src/LKM (Debian didn't have a /usr/src/linux/include, rather it put the .h files in /usr/include) and ran make. Everything is fine with one problem - kernel_wrappers.c line 49 asks for net/sock.h. This file doesn't exist anywhere on my system. Since kernel_wrappers doesn't compile, I don't get lomac_mod.o. Lup compiles fine (no surprises there I guess). Any Debian users out there who can tell me which package has the sock.h file? I was watching task-debian-devel install, and that has just about everything I can think of as far as libraries are concerned. Cheers, James From owner-lomac-users Tue Feb 20 12:28:49 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21142 Tue, 20 Feb 2001 12:28:12 -0500 (EST) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Tue, 20 Feb 2001 13:48:44 -0500 (EST) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: James Zuelow cc: lomac-users@lists.tislabs.com Subject: Re: Debian 2.2 sock.h In-Reply-To: <3A916F86.226576E3@alaska.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! > I untarred lomac-v1.0.4 into /usr/local/Lomac, and edited the Makefile > in Src/LKM (Debian didn't have a /usr/src/linux/include, rather it put > the .h files in /usr/include) and ran make. Do you have the kernel source installed? /usr/src/linux/include is part of the kernel source tree. If you don't have a /usr/src/linux, you should try installing the kernel source. You don't need the kernel source to do development on normal user-space applications, so it's possible that it wasn't installed by default. However, you do need the kernel headers to compile LOMAC, since LOMAC is effectively a kernel-space driver. Make sure you get the kernel source for the same version of the Linux kernel that you are running on the machine (or update the kernel to match the version of the source you install). If this doesn't fix your problem, please send another message and I'll try to think up another wild-goose-chase for you. :^) The current LOMAC manual doesn't mention the need for kernel source - this is is definitely something I need to fix, so thanks for bringing it up... - Tim From owner-lomac-users Wed Feb 21 00:21:57 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA23678 Wed, 21 Feb 2001 00:20:59 -0500 (EST) Message-ID: <3A9350DC.FC2701D8@alaska.net> Date: Tue, 20 Feb 2001 20:23:40 -0900 From: James Zuelow Organization: Not really X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tim Fraser CC: lomac-users@lists.tislabs.com Subject: Re: Debian 2.2 sock.h References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Tim Fraser wrote: > > Hi! > Do you have the kernel source installed? /usr/src/linux/include > is part of the kernel source tree. If you don't have a /usr/src/linux, > you should try installing the kernel source. You don't need the kernel > source to do development on normal user-space applications, so it's > possible that it wasn't installed by default. However, you do need the > kernel headers to compile LOMAC, since LOMAC is effectively a kernel-space > driver. > I did some comparisons with my RedHat boxes, and installed the kernel-headers. That lets it compile, but not start. Lomac was looking for /etc/init.d/functions, which also wasn't present (I added this). Then I started lomac, and it complained that it couldn't find /bin/awk. However I can't install awk since apt-get and dpkg are completely broken. Lomac is apparently running halfway - I can't access the level 2 directories via SSH, which makes sense, as I should be locked into level 1. But the tools in /opt/lomac/bin fail, reporting that lomac is not running. If I reboot, it should come up to the same state, since the rc.Nd symlinks are set up, but awk is not installed. I knew that getting lomac going would be an adventure (this is my firewall box - it is headless and I use SSH to manage it). Time to go find a monitor and keyboard for it. Now if it didn't have that screwy Compaq monitor port on it. I don't feel like cutting pins off of my regular monitor... Semper gumby, James From owner-lomac-users Wed Feb 21 10:35:20 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25607 Wed, 21 Feb 2001 10:34:17 -0500 (EST) Date: Wed, 21 Feb 2001 10:36:48 -0500 (EST) From: Timothy Fraser X-Sender: tfraser@clipper.gw.tislabs.com To: James Zuelow cc: lomac-users@lists.tislabs.com Subject: Re: Debian 2.2 sock.h In-Reply-To: <3A9350DC.FC2701D8@alaska.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! Thanks for trying all this stuff out on Debian! I've been trying to get a Debian 2.2rev0 box together for LOMAC, but I've never managed to get the modular network card drivers to load properly. It seems that my LOMAC scripts are much more RedHat-specific than I intended - this will have to be fixed. > I did some comparisons with my RedHat boxes, and installed the > kernel-headers. That lets it compile, but not start. Lomac was looking > for /etc/init.d/functions, which also wasn't present (I added this). This is good info - I wanted the LOMAC rc script to be distribution-independent, but it seems that it relies on RedHat's functions file. I'll have to remove this dependency. > Then I started lomac, and it complained that it couldn't find /bin/awk. > However I can't install awk since apt-get and dpkg are completely > broken. Lomac is apparently running halfway - I can't access the level > 2 directories via SSH, which makes sense, as I should be locked into > level 1. But the tools in /opt/lomac/bin fail, reporting that lomac is > not running. If I reboot, it should come up to the same state, since > the rc.Nd symlinks are set up, but awk is not installed. OK, this makes sense. The LOMAC utility programs communicate with the LOMAC kernel module through a character special file called /dev/lomac. One of the LOMAC startup scripts tries to create /dev/lomac using mknod shortly after the LOMAC kernel module loads. To do so, the startup script must find out what character device minor number the kernel module is using. (The kernel module asks the kernel for any free number, so it could be a different number on each boot.) It tries to use awk to read the number out of the "lomac" line in /proc/devices. However, if you don't have awk, the startup script can't create /dev/lomac, and the LOMAC utility scripts won't work. As a quick fix, you could try creating /dev/lomac yourself. Although LOMAC might get a different device number on each boot in theory, I suspect that it tends to get the same number every time in real life. In the long run, I'll have to change the script to use something other than awk. Did your Debian box have Perl on it by default? Perhaps Perl would be a more compatible choice. On the topic of SSH, Lee Badger suggested that I change the default policy to allow remote level-2 root logins via ssh. I suspect that all this would require would be adding the ssh daemon to the Trusted Program List, but I haven't tried it. If you or anyone else tries this out, please let me know how it works out. > I knew that getting lomac going would be an adventure (this is my > firewall box - it is headless and I use SSH to manage it). Time to go > find a monitor and keyboard for it. Now if it didn't have that screwy > Compaq monitor port on it. I don't feel like cutting pins off of my > regular monitor... I also run my firewall box headless. I've hooked an old DEC VT420 dumb terminal to it to allow me to fool with the configuration. I got the old terminal at a "Hamfest" for US$4. Hamfests are flea-markets set up by Amateur radio enthusiasts, but there's usually as much old computer stuff as radio stuff to be found at them. You can get a schedule of hamfests in the US at www.arrl.org. Maybe a terminal would be a good solution for your headless firewall, too. - Tim From owner-lomac-users Thu Feb 22 03:24:03 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA28770 Thu, 22 Feb 2001 03:23:36 -0500 (EST) Message-ID: <3A94CD2C.218E53F8@alaska.net> Date: Wed, 21 Feb 2001 23:26:20 -0900 From: James Zuelow Organization: Not really X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Timothy Fraser CC: lomac-users@lists.tislabs.com Subject: Re: Debian 2.2 sock.h References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Timothy Fraser wrote: > > Hi! > > Thanks for trying all this stuff out on Debian! I've been trying > to get a Debian 2.2rev0 box together for LOMAC, but I've never managed to > get the modular network card drivers to load properly. It seems that my > LOMAC scripts are much more RedHat-specific than I intended - this will > have to be fixed. > Tim, It might take some work. I ended up scrounging a monitor and going into linux single to remove Lomac. It had demoted sshd, so that sshd could not write to the logs. (That led to the interesting situation where I could log in via ssh, but who and w did not know that - since there was no record of my logging in anywhere.). It then demoted cron and anacron (demoted anacron becuase anacron read from the cron.daily file). Cron and anacron could not log either. It demoted ipchains (IMHO should always be level 2) so I was no longer getting ipchains logs. And it demoted pppd, which meant that not only was pppd unable to write to the logs, but it was unable to dial out. I did a `cat /var/log/messages | grep LOMAC` and the list of daemons is impressive. This may be related to my not having awk installed before installing Lomac, or it may be related to RedHat and Debian placing quite a few files in different locations. The default list of trusted files may have to be tweaked for debian. Do you want the grepped log I mentioned? Cheers, James -- Semper Gumby From owner-lomac-users Thu Feb 22 13:03:24 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00885 Thu, 22 Feb 2001 13:02:55 -0500 (EST) Date: Thu, 22 Feb 2001 13:05:45 -0500 (EST) From: Timothy Fraser X-Sender: tfraser@clipper.gw.tislabs.com Reply-To: Timothy Fraser To: James Zuelow cc: lomac-users@lists.tislabs.com Subject: Re: Debian 2.2 sock.h In-Reply-To: <3A94CD2C.218E53F8@alaska.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! > It might take some work. Fixing LOMAC isn't work - it's play! :^) > It had demoted sshd, so that sshd > could not write to the logs. (That led to the interesting situation > where I could log in via ssh, but who and w did not know that - since > there was no record of my logging in anywhere.). Demoting sshd is correct behavior according to the current policy, although I've been thinking of making sshd a trusted program, as discussed earlier. The utmp and wtmp log files you mention are a tough problem for LOMAC: if I put them at level 2, they're protected from tampering, but level-1 programs (like remote logins) can't write log entries to them. On the other hand, if I put them at level 1, everyone can write their log messages to them, but LOMAC won't protect them from tampering. Right now I've set the default policy to use the level-2 option for utmp and the level-1 option for wtmp. This may not be an optimal arrangement. Programs like "who" consult utmp by default, so that's the explanation for the disturbing lack of logs you saw. > Do you want the grepped log I mentioned? Yes, please mail them to me - they'll help me fix the problems you saw with pppd, cron, etc. (You probably don't need to CC them to the list.) Thanks for your help! - Tim From owner-lomac-users Sat Mar 3 10:21:39 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06788 Sat, 3 Mar 2001 10:20:38 -0500 (EST) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Sat, 3 Mar 2001 11:41:35 -0500 (EST) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: James Zuelow cc: lomac-users@lists.tislabs.com Subject: SSH (was LOMAC on Debian) In-Reply-To: <3AA0741A.B3860325@alaska.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! > I'll try this on Sunday or Monday, as I have time. Thanks! > Are you thinking of setting up SSH as a trusted application in the > standard LOMAC version, or forking LOMAC into standard and remote > management versions? I can see where some people would be in my > position, where using SSH is useful (or even required for truly remote > servers). However I am sure that other people want a box where all > network connectivity is forced to level 1, regardless of protocol. This is a good question, and I'm not sure of the answer yet. I'll cc: this reply to lomac-users, to see if anyone else has any suggestions. On one hand, making sshd trusted would help to support LOMAC's one-size-fits-all and ease-of-use claims. On the other hand, it reduces the protection LOMAC's default policy provides by making the bug-freeness of sshd and the security of ssh passwords/keys an issue, as you noted. I faced a similar question earlier with pump - the client-side DHCP daemon. Pump needed to be trusted to work, since it reads from the network and tries to modify configuration files like /etc/resolv.conf. I decided to include it in the list of trusted programs for the sake of DHCP users, even though static-IP users don't need it, or the risk it implies. I figured that static-IP users wouldn't run pump, so it wouldn't be remotely exploitable. That argument doesn't apply for sshd, since even users who don't need level-2 remote management sessions might have sshd running to allow level-1 remote access. So, I'm still thinking about it. - Tim From owner-lomac-users Tue Mar 20 12:57:50 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05919 Tue, 20 Mar 2001 12:57:14 -0500 (EST) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Tue, 20 Mar 2001 14:19:00 -0500 (EST) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: lomac-users@lists.tislabs.com cc: jfzuelow@alaska.net, tfraser@tislabs.com Subject: LOMAC v1.0.5 on FTP site In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! LOMAC v1.0.5 is now available for download at: ftp://ftp.tislabs.com/pub/lomac/lomac-v1.0.5.tar.gz Changes in LOMAC v1.0.5: o LOMAC now allows remote level-2 root logins via ssh. o Fixed mediation logging to accurately report which operation (open, unlink, etc.) was denied. o Took RedHat-specific code out of initialization scripts to allow installation on other distributions. o Updated manual to include specific installations instructions for RedHat and Debian distributions, as well as some new text on using lup and ssh. o Tweaked the lup program to retain the names of upgraded files. - Tim From owner-lomac-users Tue May 8 13:33:29 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23220 Tue, 8 May 2001 13:32:58 -0400 (EDT) From: tfraser@tislabs.com Date: Tue, 8 May 2001 13:56:25 -0400 Message-Id: <200105081756.NAA05096@bucky.gw.tislabs.com> X-Authentication-Warning: bucky.gw.tislabs.com: tfraser set sender to tfraser@bucky.gw.tislabs.com using -f To: lomac-users@lists.tislabs.com Subject: kernel security BOF at USENIX Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! NAI Labs is sponsoring a Birds-Of-a-Feather (BOF) session at the 2001 USENIX Annual Technical Conference to give members of the Open Source kernel security community a chance to meet and discuss ideas in person. Crispin Cowan (WireX), Peter Loscocco (NSA), Amon Ott (RSBAC) and Robert Watson (NAI Labs and the FreeBSD Project) have kindly agreed to kick off the session with short presentations on their work. The remainder of the session will be a relatively informal event; the specific issues addressed will be determined by the participants. The posted agenda is as follows: Representatives of several Linux and FreeBSD security projects will present their work and views on providing new support for kernel security extensions. Presenters will include Crispin Cowan (WireX/Immunix), Peter Loscocco (NSA/SELinux), Amon Ott (RSBAC), and Robert Watson (NAI Labs/TrustedBSD). A question and answer period will follow. During this period, all participants will be free to introduce issues that they feel are of critical importance. Likely topics of discussion include requirements for general policy support, the hook-based implementation efforts spawned by the 2001 Linux Kernel Summit, and the future of security in the FreeBSD and Linux kernels. This BOF should be one of several events of interest at the 2001 USENIX Annual Technical Conference. There are five technical sessions with "Security" in their titles. In one of these sessions, Stephen Smalley will be presenting a paper on the NSA's Security-Enhanced Linux project, Robert Watson will be presenting a paper on TrustedBSD, and I (Tim Fraser) will be presenting a paper on LOMAC. The conference is scheduled for 25-30 June 2001 in Boston, Massachusetts, USA. The BOF will be from 8PM to 10PM on Thursday, 28 June. More details can be found at: http://www.usenix.org/events/usenix01/ . - Tim Fraser, NAI Labs From owner-lomac-users Fri May 11 12:50:15 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02776 Fri, 11 May 2001 12:48:21 -0400 (EDT) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Fri, 11 May 2001 13:12:12 -0400 (EDT) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: lomac-users@lists.tislabs.com cc: tfraser@tislabs.com, rwatson@tislabs.com Subject: LOMAC v1.1.0 on FTP site Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! LOMAC v1.1.0 is now available for download at: ftp://ftp.tislabs.com/pub/lomac/lomac-v1.1.0.tar.gz Changes in LOMAC v1.1.0 since the last release (v1.0.5): o Restructured argument handling to avoid time-of-check/time-of-use errors. o Added mediation on the addition and removal of directory entries. o Changed all -EPERM ("operation not permitted") return values to the proper value: -EACCES ("permission denied"). Summary of Changes in LOMAC v1.1.0 since the v1.0.0 release: The 1.1.0 release improves LOMAC's protective functionality and makes LOMAC easier to use. The 1.1.0 release features restructured system call argument handling to addresses the time-of-check/time-of-use problems present in the 1.0 release, and provides new mediation on directory modification operations. With the 1.1.0 release, LOMAC's default configuration allows the mounting of remote NFS filesystems and the use of SSH for remote administration. - Tim From owner-lomac-users Fri May 11 18:38:35 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04195 Fri, 11 May 2001 18:38:27 -0400 (EDT) From: Rob M To: Date: Fri, 11 May 2001 22:44:45 "GMT" X-MSMail-Priority: Normal X-mailer: AspMail 3.03 (SMTPEE7B4F) Subject: Immunix Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200105111731609.SM00152@MYPWP1> Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Has anyone tested Lomac on Immunix or StackGuard? I installed / compiled and I get /opt/lomac/bin/lomac_mod.o: unresolved symbol __canary_death_handler when I try to insmod. Thanks, RM http://immunix.org/stackguard.html __________________________________________________ Where can you e-mail your friends and e-file your tax returns for FREE? http://MyHDVEST.com Makes Life Click! From owner-lomac-users Sat May 12 05:04:57 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA05929 Sat, 12 May 2001 05:04:54 -0400 (EDT) Date: Sat, 12 May 2001 11:07:38 +0200 From: Nicolai Schleifer To: Rob M , lomac-users@lists.tislabs.com Subject: Re: Immunix Message-ID: <20010512110738.B17036@ns.cc-0.dom.de> References: <200105111731609.SM00152@MYPWP1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105111731609.SM00152@MYPWP1>; from rmorrow@hdvestmail.com on Fri, May 11, 2001 at 10:44:45PM +0000 X-Sender: 520066205126-0001@t-dialin.net Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk lomac with immunix works fine. you cannot compile kernels or kernel modules with the stock immunix gcc. how to compile kernels or kernel modules on an immunix system: i don't know if this the imperial standard procedure, but i install the stock redhat 6.2 egcs to compile kernels or kernel modules on immunix. when you are done, you can re-install the immunix enabled rpms. i needed the rescue cdrom to reinstall the immunix stuff properly afterwards, since i have tweaked the system and updated rpm to 4. i can remember that this worked more smoothly and without any rescue system using _standard_ immunix rpms/updates and _standard_ rh 6.2 rpms/updates. i install the following stuff before compiling kernels on immunix 6.2: egcs-1.1.2-30.i386.rpm glibc-devel-2.1.3-15.i386.rpm egcs-c++-1.1.2-30.i386.rpm libstdc++-2.9.0-30.i386.rpm glibc-2.1.3-15.i386.rpm (beware there are updated versions of especially glibc, due to security reasons on any redhat mirror) after compiling the kernel, just re-install the corresponding immunix packages and reboot. i have to admit that i did not tripwire the system before and after using this procedure. i would like to know if this has been done and if this shows any misfits with the files. i suggest to use aide for this (http://www.cs.tut.fi/~rammer/aide.html). note, the immunix staff recommends NOT to pollute the system with non stackguarded rpms, which is what you are doing when you install plain redhat rpms for kernel compilation. rpm installation is not necessarily an invertable operation (unfortunately). ns On Fri, May 11, 2001 at 10:44:45PM +0000, Rob M wrote: > Has anyone tested Lomac on Immunix or StackGuard? I installed / compiled and I get /opt/lomac/bin/lomac_mod.o: unresolved symbol __canary_death_handler when I try to insmod. From owner-lomac-users Sun May 13 12:40:44 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08465 Sun, 13 May 2001 12:40:20 -0400 (EDT) Date: Sun, 13 May 2001 11:45:34 -0500 To: lomac-users@lists.tislabs.com Cc: linas@linas.org Subject: chroot Message-ID: <20010513114534.B5955@backlot.linas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi, Doesn't look like you are being slashdotted yet ... I read all about lomac, really really liked the concept, and decided to give it a whirl ... even trying it on a production machine (breifly). Ran into a problem immediately, thought I'd let you know: chroot To provide a level of security, several programs use chroot in an attempt to limit damage from e.g. stack-smashing attempts. The two on my system: named and postfix. I didn't run lomac long enough to spot problems with amed, but postfix (a 'more secure' email handler) ran into the chroot problem immediately. It consists of a half-dozen agents (processes) to pick up, sort and deliver mail. May 13 09:35:34 www kernel: LOMAC: p578g381u89:cleanup level 1 denied open of /incoming/971816.578 level 2 cleanup is actually trying to read (and eventually unlink??) /var/spool/postfix/incoming/971816.578 It would seem that it must have chroot'ed to /var/spool/postfix before doing what it does; and that lomac doesn't implement chroot; otherwise, I can't understand the error message. I assme that I can work around this problem by ln -s /var/spool/postfix/incoming/ /incoming and likewise, any other directories that pop up this way. Haven't yet tried to do so. Thus, a request: at least add something to BUGS explaining this; ideally, 'fix it'. (and hey, a big request: a port to kernel 2.4). ((and double-hey: your basic concepts seem clean and sound enough that I'd encourage you to start talking to Torvalds about modifying whatever kernel structures you need to add the needed level fields to the e.g. 2.5 linux kernel ...)) I'll give the link idea a spin sometime in the next few days, and report the results. But it does make me nervous. This linking idea may be OK for postfix, but for named, I'm more nervous, since named expects /var/run and /etc/named and /usr/sbin/ in its chrooted environment .... --linas -- Linas Vepstas -- linas@linas.org -- http://www.linas.org/ From owner-lomac-users Sun May 13 13:04:00 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08501 Sun, 13 May 2001 13:03:55 -0400 (EDT) Date: Sun, 13 May 2001 12:09:07 -0500 To: lomac-users@lists.tislabs.com Cc: linas@linas.org Subject: print shells demotions to stdout Message-ID: <20010513120907.A6104@backlot.linas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi, Another request: it would be cute & useful to have a little message print to stdout whenenver a user running an interactive shell at level 2 does something that demotes the shell to level 1. I managed to demote myself somehow, wasn't paying attention, and then ran shutdown -r The shutdown itself suceeded (although I suppose it really shouldn't have), but various parts of shutdown (like unmounting the filesystems) failed spectacularly, thus causing a systemwide fsck upon reboot )-: --linas -- Linas Vepstas -- linas@linas.org -- http://www.linas.org/ From owner-lomac-users Mon May 14 01:02:32 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA09604 Mon, 14 May 2001 01:02:25 -0400 (EDT) Date: Mon, 14 May 2001 00:07:36 -0500 To: lomac-users@lists.tislabs.com Cc: linas@linas.org Subject: Re: print shells demotions to stdout Message-ID: <20010514000736.A7144@backlot.linas.org> References: <20010513120907.A6104@backlot.linas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010513120907.A6104@backlot.linas.org>; from linas@linas.org on Sun, May 13, 2001 at 12:09:07PM -0500 From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk What I wrote earlier is wrong. On Sun, May 13, 2001 at 12:09:07PM -0500, Linas Vepstas was heard to remark: > > I managed to demote myself somehow, wasn't paying attention, and > then ran shutdown -r The shutdown itself suceeded (although > I suppose it really shouldn't have), but various parts of shutdown > (like unmounting the filesystems) failed spectacularly, thus > causing a systemwide fsck upon reboot )-: This is not right. The shutdown did indeed start at level 2. Helfway through, the rc6d./K50postfix script ran. It grabbd the pid of the postfix program from /var/spool/postfix/pid and got demoted. Although it could kill the level-1 postfix master program, the subsequent unmounts failed. I looked at the postfix source code; there doesn't seem to be any compelling reason why it uses the /var/spool/postfix/pid directory, and it seems it could be recompiled to use /var/run instead. I'll see if I can ask the postfix maintainers .. --linas -- Linas Vepstas -- linas@linas.org -- http://www.linas.org/ From owner-lomac-users Mon May 14 01:39:46 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA09697 Mon, 14 May 2001 01:39:44 -0400 (EDT) Date: Mon, 14 May 2001 00:44:57 -0500 To: lomac-users@lists.tislabs.com Cc: linas@linas.org Subject: /var/lock/subsys ??? Message-ID: <20010514004457.A7286@backlot.linas.org> References: <20010513120907.A6104@backlot.linas.org> <20010514000736.A7144@backlot.linas.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010514000736.A7144@backlot.linas.org>; from linas@linas.org on Mon, May 14, 2001 at 12:07:36AM -0500 From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I gess I love spamming mailing lists ... On Mon, May 14, 2001 at 12:07:36AM -0500, Linas Vepstas was heard to remark: > This is not right. The shutdown did indeed start at level 2. > Helfway through, the rc6d./K50postfix script ran. It grabbd the pid > of the postfix program from /var/spool/postfix/pid and got demoted. The 'obvious' solution is to=20 { LOMAC_HIGHEST_LEVEL, PLM_NOFLAGS, "/var/spool/postfix/pid" }, (I chickened out about writing to Weitse Venema about changing=20 the location of its pid file to /var/run ... I didn't really feel=20 like I had a good enough argument for the change ...) Anyway, while reviewing the scripts in /etc/rc.d/init.d, I noticed that many/most of them touched /var/lock/subsys/* and it now strikes me ... why did it seem that these scripts=20 don't get demoted during bootup? (I'm afraid of checking this right now, since my test machine is also a production machine ...) Am I missing something? Or is it correct that anything started with /etc/rc.d/init.d scripts gets demoted? I ask this, because the shutdown scripts all rm -f things in /var/lock/subsys ... does this imply that unlinking level-1=20 file does not demote a level-2 subject ? It seems to me it would be a not-bad idea to add /var/lock/subsys to the plm ... or is it ??? --linas --=20 Linas Vepstas -- linas@linas.org -- http://www.linas.org/ --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6/3DZZKmaggEEWTMRAgvbAJ9djBviAqMmb0+yQ+lUzGrXs//l4ACgidzd hoIrVVwtlEeCbZGOikploZE= =5Q3+ -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From owner-lomac-users Mon May 14 13:10:30 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11984 Mon, 14 May 2001 13:08:31 -0400 (EDT) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Mon, 14 May 2001 13:32:48 -0400 (EDT) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: Linas Vepstas cc: lomac-users@lists.tislabs.com Subject: Re: /var/lock/subsys ??? In-Reply-To: <20010514004457.A7286@backlot.linas.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! lv> I read all about lomac, really really liked the concept, and decided lv> to give it a whirl ... even trying it on a production machine Thanks for your feedback on LOMAC! I've never run postfix, so the PLM isn't set up to handle it yet. Thanks for bringing it up - this definitely needs to be fixed. If we can figure out what rules need to be added in order to support postfix, I'll put them in the next release. lv> It would seem that it must have chroot'ed to /var/spool/postfix before lv> doing what it does; and that lomac doesn't implement chroot; lv> otherwise, I can't understand the error message. LOMAC sees pathnames only after the kernel has translated them into canonical absolute form - that is, after the kernel has resolved all chroots and symbolic links. So, that's why LOMAC reported "/var/spool/postfix/incoming" instead of the chroot version, "/incoming". All the PLM rules are in terms of the system's single true "/" dir. lv> I assme that I can work around this problem by lv> ln -s /var/spool/postfix/incoming/ /incoming As you've probably guessed after reading the above paragraph, adding this symbolic link wouldn't help. We need to add a rule to the PLM for "/var/spool/postfix". (See below). lv> I managed to demote myself somehow, wasn't paying attention, and then lv> ran shutdown -r The shutdown itself suceeded (although I suppose it lv> really shouldn't have), but various parts of shutdown (like unmounting lv> the filesystems) failed spectacularly, thus causing a systemwide fsck lv> upon reboot )-: Yes, this is an annoying behavior. Since the shutdown program is not aware of LOMAC, it doesn't check to make sure it's at level 2 before kicking off all of the shutdown scripts. Some of the scripts kill level-1 processes, which works. However, some try to kill level-2 processes and delete level-2 files, which fails as you observed. The reboot syscall itself succeeds, because I have the level check on that syscall commented out right now. I'll add a description of this surprising behavior to the next BUGS file. lv> The 'obvious' solution is to lv> lv> { LOMAC_HIGHEST_LEVEL, PLM_NOFLAGS, "/var/spool/postfix/pid" }, Yes, this is how I would (try to) solve the problem. I'd also stick in a rule: { LOMAC_LOWEST_LEVEL, PLM_NOFLAGS, "/var/spool/postfix" }, to allow postfix to move mail around once it's at level 1. If you have the time, I'd appreciate it if you'd give this a try and let me know if it works. Be sure to keep the PLM sorted by length, and increase the NUM_PLM_RULES constant appropriately. lv> I ask this, because the shutdown scripts all rm -f things lv> in /var/lock/subsys ... does this imply that unlinking level-1 lv> file does not demote a level-2 subject ? Yes, only reads and exec's cause demotion. Writes, creats, mkdirs, mknods, unlinks, etc. don't cause demotions. lv> (and hey, a big request: a port to kernel 2.4). Yes, this is already high on my things-to-do list. lv> that I'd encourage you to start talking to Torvalds about modifying lv> whatever kernel structures you need to add the needed level fields to lv> the e.g. 2.5 linux kernel ...)) In the wake of this year's Linux Kernel Summit, Torvalds declared that he wanted to see a general set of "hooks" placed at strategic places in the kernel to support access control extensions. These hooks would be function pointers that the kernel would use to call out to security modules whenever it needed them to make access control decisions. Torvalds saw hooks as a better alternative to patching specific forms of mandatory access control in the kernel. That way, everyone could use whatever security module they wanted (if any). An effort is already under way in the community to produce a good set of hooks (see http://lsm.immunix.org). Once the hooks are in the kernel, security modules like LOMAC will probably perform much better. Thanks again for your feedback! - Tim From owner-lomac-users Mon May 14 15:54:46 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA12430 Mon, 14 May 2001 15:54:03 -0400 (EDT) Date: Mon, 14 May 2001 14:59:16 -0500 To: Tim Fraser Cc: Linas Vepstas , lomac-users@lists.tislabs.com Subject: Re: /var/lock/subsys ??? Message-ID: <20010514145916.A8486@backlot.linas.org> References: <20010514004457.A7286@backlot.linas.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from tfraser@tislabs.com on Mon, May 14, 2001 at 01:32:48PM -0400 From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, May 14, 2001 at 01:32:48PM -0400, Tim Fraser was heard to remark: > Thanks for your feedback on LOMAC! =20 You're welcome. Read the usenix paper and all; I'm no security expert, but lomac seems more sane & rational than most other proposals that I have tripped across. Good stuff. > I've never run postfix,=20 For the security paranoid, its a fixture. And a good bit easier to configure than sendmail. > lv> It would seem that it must have chroot'ed to /var/spool/postfix before > lv> doing what it does; and that lomac doesn't implement chroot; > lv> otherwise, I can't understand the error message. >=20 > LOMAC sees pathnames only after the kernel has translated them > into canonical absolute form - that is, after the kernel has resolved all > chroots and symbolic links. So, that's why LOMAC reported > "/var/spool/postfix/incoming" instead of the chroot version, "/incoming". On the contrary:=20 kernel: LOMAC: p578g381u89:cleanup level 1 denied open of /incoming/971816.= 578 level 2 > We need to add a rule to the PLM for "/var/spool/postfix". =20 I can do that, but ... wouldn't /var/spool/postfix already be level 1 by default? indeed, your source code has=20 { LOMAC_LOWEST_LEVEL, PLM_CHILDOF, "/var" }, and so don't subdirectories inherit this 'lowest' rating? so I cannot understnand the above error message unless I assume that { LOMAC_HIGHEST_LEVEL, PLM_NOFLAGS, "/" } was the rule that was being applied instead.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D It would be very nice if there was a debug/trace mode in the thing: a way to have the lkm perform the checks, print the messages, but not take any action. Ahh .. I see ... #define NO_MEDIATION in lomac_mediate.c ... That would be another good one to document int=20 the README.=20 =2E.. as would 'verbose' in lomac_log.c ... Might be a good idea to move all such configuration stuff (including the plm rules, etc). to a "lomac_config.h" ... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Yes, this is an annoying behavior. Since the shutdown program is > not aware of LOMAC, it doesn't check to make sure it's at level 2 before > kicking off all of the shutdown scripts. Some of the scripts kill level-1 > processes, which works. However, some try to kill level-2 processes and > delete level-2 files, which fails as you observed. The reboot syscall > itself succeeds, because I have the level check on that syscall commented > out right now. I'll add a description of this surprising behavior to the > next BUGS file. What's the long-term philosophy on this? Are you hoping to create shell-script wrappers that first check for level 2, and refuse to run=20 the thing if not? Seperately, what do you want to do if a level-2 subject starts shutdown, but some shutdown script observes a level-1 object? I notice you have #ifdef TRUST in your code: do you want to trust shutdown if it has been started by a level-2 user? Or would you rather manually crawl through any file that a shutdown script might read, and add that to the plm?=20 The latter seems safer ... > Yes, this is how I would (try to) solve the problem. I'd also > stick in a rule: >=20 > { LOMAC_LOWEST_LEVEL, PLM_NOFLAGS, "/var/spool/postfix" }, >=20 > to allow postfix to move mail around once it's at level 1. =20 See above, I don't see why it doesn't default to level 1. --linas > If you have > the time, I'd appreciate it if you'd give this a try and let me know if it > works. =20 I'll give it a shot. > Be sure to keep the PLM sorted by length, and increase the > NUM_PLM_RULES constant appropriately. how about using 'sizeof' instead of a #define constant? That way, you can avoid stupid counting errors ... plm_rule_t plm[] =3D { { LOMAC_HIGHEST_LEVEL, PLM_NOFLAGS, "/var/lock/subsys" }, =2E.. }; #define NUM_PLM_RULES (sizeof (plm)/sizeof (plm_rule_t)) much cleaner code, in my opinion. The sizeof's are computed at compile time, and stored in a .rodata or .data section during load. --linas --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7ADkUZKmaggEEWTMRAuhOAJ0TXztQ+0Q1iWUYsFq3WmjUz2vsdQCeIxCs ooCqSuZOBAKhQGSwGLQ3ebE= =bskP -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-lomac-users Mon May 14 21:06:35 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA13181 Mon, 14 May 2001 21:06:28 -0400 (EDT) Date: Mon, 14 May 2001 20:11:42 -0500 To: lomac-users@lists.tislabs.com, tfraser@tislabs.com Subject: three levels of security Message-ID: <20010514201142.A9251@backlot.linas.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline User-Agent: Mutt/1.3.17i From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, After looking at lomac_plm.c and lomac_tpl.c and seeing /home/httpd there, and seeing /usr/sbin/sshd there, I started thinking... First, I thought, "gee what a great idea, I'll just add /home/linas/public_html (that's where my web pages are located)=20 to the list of trusted level 2's and that way some hacker can't clobber=20 me ... what the hell, lets make all of /home/linas trusted, that'll make sysadmin easier." =20 Next I thought to myself "Hey what a dumb idea. All my downloaded code is in /home/linas, and it could be full of trojans, etc. Doing this would clearly violate the whole point of LOMAC." Then I thought "Gee, it sure would be nice to protect my web pages, though"...=20 Then I thought "Hey, this lomac guy is violating his own credo by trusting /home/httpd" ... And then the lightbulb hit: how about 3 levels of security? The highest protects /usr and /bin and /etc and attempts to make these directories as immutable as possible. The mid-level protects peoples home dirs, web pages, ftp site contents. The lowest level is the default level for anything that connects to the net. Thus, httpd runs at level1. And if anyone is able to hack into my httpd (e.g. via bad php scripts, or zope, or wiki-wiki or a poorly written perl script, or a defective Java servlet), they may be able to get root, but they still won't be able to deface=20 my web pages (which are at mid-level). Nor will they be able to leave behind a back-door Java servlet ...=20 ---------- The basic idea is this: the mid-level is 'semi-trusted'. It is suceptible to trojans accidentally copied in by users using ssh/scp; However, it is protected from worms that crack web sites. =20 --------------- I haven't really thought this through. Its half baked. There may well be objections that it raises 'total compatibility cost', because mid-level users will have trouble manipulating thier low-level email ... On the other hand, maybe one could make *all* local binaries 'trusted' at mid-level (i.e. mid-level subject could read level-1 objects without demotion). ------- What do you think? If this has been considered before, and concluded to be a bad idea, let me know. If this is a 'good idea', but 'not right for lomac', let me know. =46rom reading the above, you can clearly see what I'm afraid of:=20 malicious hackers breaking into my fancy website, and either=20 defacing or gaining root. What I am not afraid of (at least=20 not much), is a trojan or virus that was accidentally=20 introduced. That's because true wild-strain trojans (as opposed to your prankster office mates) seem to be very rare or non-existant ... so far ... in the unix world. But remote breakins are dime-a-dozen, especially when you load up you web site with the latest joe-blow-gimmick cgi-bin.=20 --linas --=20 Linas Vepstas -- linas@linas.org -- http://www.linas.org/ --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7AIJOZKmaggEEWTMRAn9fAJ48OfwnMR9q/ZrPUFOlKNmUxnvozACbB6Xf QTUrG6gJKw1sDiYs1tM3EtQ= =uX51 -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-lomac-users Tue May 15 02:06:23 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA13678 Tue, 15 May 2001 02:06:13 -0400 (EDT) Date: Tue, 15 May 2001 00:48:28 -0500 To: lomac-users@lists.tislabs.com, tfraser@tislabs.com Cc: linas@linas.org Subject: chroot, again Message-ID: <20010515004828.A9691@backlot.linas.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline User-Agent: Mutt/1.3.17i From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi again. Am I being too chatty? =20 I looked at the chroot problem again, and its more serious than you might think. linux/fs/open.c implements sys_chroot(dentry *) the critical line of code is: current->fs->root =3D dentry; That's it; after a chroot, the root pointer for the fs_struct in=20 the linux task_struct (linux/include/linux/sched.h) is set to this new root, and *any* memory of the true filesystem root is really, really lost for this subject/task. That is, d_path() (in linux/fs/dcache.c) returns the path relative to=20 current->fs->root, which is not the 'true root' of the filesystem.=20 Thus, the power of the chroot gaol.=20 Since make_canabspath() uses d_path, its guarenteed to get=20 something that is not really the 'real' canonical absolute path=20 for a chrooted subject. There is no 'obvious' way to traverse the linux task_struct to find the 'true' root of the file system. No problem, I say, I'll just write a chroot wrapper for lomac,=20 and record the original root in some lomac structure. Oops ... =20 typedef struct task_struct lomac_subject_t; so there seems to be no place to store the 'true root' anywhere, without modifying the kernel. dead end ... unless we do a stunt: struct lomac_subject_s { struct task_struct task; struct dentry *true_root; }; typedef struct lomac_subject_s lomac_subject_t; and modify lomac code here and there to use this new struct. These modification are a bit deeper than I want to go without a serious discussion with the authoer as to whether this would indeed be the best implementation, who will implement this, and if I do it, whether my patches will be accepted. The last thing I need to do right now is to create a lomac patch that=20 will be turned down ... Eagerly waiting your reply... Lomac is the first thing I've stumbled across that promises to make me sleep better at night, while them thar hackers are busy trying to root my web server. (fwiw, I get a half-dozen port scans a day now, and I don't know how many attempts on weaknesses on port 80. Someday, someone will suceed in getting in...) --linas --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7AMMsZKmaggEEWTMRAuN9AJ0USv7uBvqdfGfZJNNRbqsM2MoEhwCfYary x0Xq/I3Sc0U7x1cS0Qe2/cU= =MdGV -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-lomac-users Tue May 15 02:56:13 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA13878 Tue, 15 May 2001 02:56:12 -0400 (EDT) Date: Mon, 14 May 2001 23:11:50 -0500 To: lomac-users@lists.tislabs.com, tfraser@tislabs.com Subject: pgrp problems Message-ID: <20010514231150.A9522@backlot.linas.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline User-Agent: Mutt/1.3.17i From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, One last note for the day -- there seems to be some sort of pgrp problem in lomac. I read the paper, and have a vague idea of why you've classed demotions together into a pgrp. But ... Here's the problem: During boot, /sbin/init (level 2) is running. It reads /etc/inittab, which says that the shell script /etc/rc.d/rc should run (at level 2). =20 rc runs, walking over the S?? files in /etc/rc.d/rc?.d One of these launches /sbin/crond, which then touches /var/spool/cron/root, which demotes crond to level 1. =20 Appearnetly (it is not clear from the log messages), this pushes the shell script /etc/rc.d/rc back to level 1, and so booting is completed at level 1. Unfortunately, this is bad, as there remains a fair amount of initialization that follows that needs to run at level 2, including an echo 1 > /proc/sys/net/ipv4/ip_forward I could try reorganizing the boot process so that crond gets started later, but fundamentally, this weems wrong (too high a=20 'compatability cost'). The 'right thing' would be to have crond somehow get its own process group (I guess??) or=20 somehow isolate it so it doesn't demote rc.=20 I'll try debugging this for a while ... but comments/help would be appreciated. My time is limited ... --linas --=20 Linas Vepstas -- linas@linas.org -- http://www.linas.org/ --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7AKyGZKmaggEEWTMRAjWyAJ97b6rtf/ve981CQoF4PaoVWthrbACfdC2y z+6XykYcKnuZpvauQdfNjo0= =oqco -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-lomac-users Tue May 15 03:12:55 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA13956 Tue, 15 May 2001 03:12:52 -0400 (EDT) Date: Mon, 14 May 2001 23:40:21 -0500 To: lomac-users@lists.tislabs.com, tfraser@tislabs.com Subject: Re: pgrp problems Message-ID: <20010514234021.A9627@backlot.linas.org> References: <20010514231150.A9522@backlot.linas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010514231150.A9522@backlot.linas.org>; from linas on Mon, May 14, 2001 at 11:11:50PM -0500 From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk On Mon, May 14, 2001 at 11:11:50PM -0500, linas was heard to remark: > One of these launches /sbin/crond, which then touches > /var/spool/cron/root, which demotes crond to level 1. > Appearnetly (it is not clear from the log messages), its not cron, its something else ... hunting ... From owner-lomac-users Tue May 15 12:48:10 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15634 Tue, 15 May 2001 12:46:46 -0400 (EDT) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Tue, 15 May 2001 13:11:14 -0400 (EDT) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: lomac-users@lists.tislabs.com Subject: LOMAC bug on later 2.2 kernels Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi. Unfortunately, there's a bug in LOMAC that prevents it from working on the later 2.2 kernels. LOMAC builds on these kernels, but causes processes to Oops (null pointer dereference) once it has been loaded. LOMAC v1.1.0 is known to work on 2.2.5 and 2.2.12. It's now known not to work on 2.2.17 and 2.2.19. There must have been some change in the kernel between 2.2.12 and 2.2.17 that LOMAC can't handle. I'm working on fixing the bug now. My tests so far show that LOMAC can initialize itself (that is, do interposition on the syscall interface and grandfather existing objects) on a 2.2.17 kernel. However, it fails when monitoring the results of open system calls. For some reason, the current->files appears null to LOMAC's wrap_open function. I'm not sure why this is, and I'm presently trying to figure it out. - Tim From owner-lomac-users Tue May 15 12:56:55 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15662 Tue, 15 May 2001 12:56:51 -0400 (EDT) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Tue, 15 May 2001 13:21:38 -0400 (EDT) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: Linas Vepstas cc: lomac-users@lists.tislabs.com Subject: LOMAC bug re: chroot In-Reply-To: <20010514145916.A8486@backlot.linas.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! Linas Vepstas has found a bug in LOMAC: LOMAC presently does not handle paths in chroot'd environments properly. LOMAC mistakenly treats the chroot'd environment's fake root as the true system root "/" when looking up paths in the PLM. This causes LOMAC to apply the wrong levels to files in chroot'd environments. lv> On the contrary: lv> kernel: LOMAC: p578g381u89:cleanup level 1 denied open of lv> /incoming/971816.578 level 2 lv> linux/fs/open.c implements sys_chroot(dentry *) lv> the critical line of code is: lv> current->fs->root = dentry; lv> That's it; after a chroot, the root pointer for the fs_struct in the lv> linux task_struct (linux/include/linux/sched.h) is set to this new lv> root, and *any* memory of the true filesystem root is really, really lv> lost for this subject/task. That is, d_path() (in linux/fs/dcache.c) lv> returns the path relative to current->fs->root, which is not the 'true lv> root' of the filesystem. Yes, you're right. My earlier suggestions about adding PLM rules were not the right solution. LOMAC's path-mangling definitely can't handle chroot properly. I suspect this problem can be solved by checking current->fs->root in make_canabspath() and prepending the chroot path in cases where current->fs->root is not the true root "/". Linas: thanks for finding this bug! - Tim From owner-lomac-users Tue May 15 13:07:59 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15722 Tue, 15 May 2001 13:07:51 -0400 (EDT) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Tue, 15 May 2001 13:32:08 -0400 (EDT) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: Linas Vepstas cc: lomac-users@lists.tislabs.com Subject: Re: three levels of security In-Reply-To: <20010514201142.A9251@backlot.linas.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! > And then the lightbulb hit: how about 3 levels of security? This is indeed a good idea. The LOMAC 0.1 and 0.2 prototypes could handle configurations with an arbitary (well, up to INT_MAX) number of levels. They could also assign different levels to each network interface. I had a 3-level LOMAC v0.2 configuration on one test box. Here's a brief description of it and its pros and cons from my upcoming USENIX paper: --- Early versions of LOMAC supported configurations with more than two levels, and allowed administrators to assign different levels to each network interface. One useful three-level configuration worked well on a host with two network interfaces: The configuration placed system objects and processes at the highest level, most local user processes, most user files and an interface to an internal network at the middle level, and the remaining servers and an interface to the an external network at the lowest level. This three-level configuration provided integrity protection to a larger portion of the system than LOMAC's present two-level configuration by bringing some user resources into the upper two protected levels. However, some user files had to remain at the unprotected lowest level where programs that read from the lowest-level network interface, such as E-mail agents and web browsers, could modify them. Consequently, the three-level configuration was more visible to non-root users than the two-level configuration, because it forced them to operate at multiple levels. For example, it forced users to run separate text editor processes for modifying lowest-level and middle-level files, and to choose the proper editor depending on the situation. Because this complexity conflicts with LOMAC's emphasis on remaining largely invisible to the user, this functionality has not yet been carried forward into the present prototype. However, future versions of LOMAC might be extended to allow site-specific configurations with many levels, and offer the existing two-level configuration as a default. In a configuration with many levels, support for programs that are trusted only in restricted ranges of levels may also be useful~\cite{lee88}. --- I'm encouraged by the fact that you've independently decided that a 3-level configuration would be useful. Eventually, I hope to add configurability as described above. - Tim From owner-lomac-users Tue May 15 13:30:45 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15805 Tue, 15 May 2001 13:29:55 -0400 (EDT) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Tue, 15 May 2001 13:54:05 -0400 (EDT) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: Linas Vepstas cc: lomac-users@lists.tislabs.com Subject: Re: chroot, again In-Reply-To: <20010515004828.A9691@backlot.linas.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! lv> There is no 'obvious' way to traverse the linux task_struct to lv> find the 'true' root of the file system. It seems I should learn to think about these problems more carefully before blithely suggesting incorrect solutions on the mailing list. :^) You were describing a potential chicken-and-egg problem in determining the absolute path of the chroot root that I hadn't considered. I still think that we can solve this problem without kernel patching or additional data structures. If all else fails, perhaps we could do something like this: if( current->fs->root != real_root ) { /* if current is chrooted */ fake_root = current->fs->root; current->fs->root = real_root; use d_path( fake_root ) to get path to fake root; current->fs->root = fake_root; prepend fake root path to canabspath; } If there's no global for real_root, we could probably get it by looking at the init process's fs->root pointer. - Tim From owner-lomac-users Tue May 15 13:41:10 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15837 Tue, 15 May 2001 13:40:58 -0400 (EDT) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Tue, 15 May 2001 14:05:30 -0400 (EDT) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: Linas Vepstas cc: lomac-users@lists.tislabs.com Subject: Re: pgrp problems In-Reply-To: <20010514231150.A9522@backlot.linas.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! lv> During boot, /sbin/init (level 2) is running. ... lv> Appearnetly (it is not clear from the log messages), lv> this pushes the shell script /etc/rc.d/rc back to level 1, lv> and so booting is completed at level 1. OK, I've run into quite a few of these problems before. I usually try and solve them by finding the file that caused the demotion, and updating the PLM to make it a level-2 file. That usually handles it; if it doesn't, we may need to make the rc script that gets demoted a trusted program. Can you determine which file caused the problem? lv> I'll try debugging this for a while ... but comments/help lv> would be appreciated. My time is limited ... Thanks for your help so far! I hope you can continue to suggest improvements for LOMAC. It'll take me some time to fix the 2.2.17 bug and the chroot bug. It's hard to predict how long these fixes will take, especially with other work-related responsibilities getting in the way. Hopefully, I'll put out fixes before the end of the month. - Tim From owner-lomac-users Tue May 15 14:11:21 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15919 Tue, 15 May 2001 14:09:42 -0400 (EDT) Date: Tue, 15 May 2001 13:14:13 -0500 To: Tim Fraser Cc: Linas Vepstas , lomac-users@lists.tislabs.com Subject: Re: chroot, again Message-ID: <20010515131413.A11023@backlot.linas.org> References: <20010515004828.A9691@backlot.linas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from tfraser@tislabs.com on Tue, May 15, 2001 at 01:54:05PM -0400 From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk On Tue, May 15, 2001 at 01:54:05PM -0400, Tim Fraser was heard to remark: > > I still think that we can solve this problem without kernel > patching or additional data structures. right. > if( current->fs->root != real_root ) { /* if current is chrooted */ > fake_root = current->fs->root; > current->fs->root = real_root; > use d_path( fake_root ) to get path to fake root; > current->fs->root = fake_root; > prepend fake root path to canabspath; > } This seems to have a race condition. If e.g. fs is shared between multiple threads, and we're scheduled out right in the middle of this call, then the other threads would see the wrong root. But I've got I think an easy bullet-proof solution. (pseudocode) you can detect the 'real' root by seeing if denetry==dentry->parent The best bet is to copy the d_path routine (its short, a few dozen lines, mostly whitespace), and remove the check if( current->fs->root == dentry) from the inner loop. Remaining in the inner loop is the check if (dentry == dentry->parent) which will terminate at the 'real root'. ================================= BTW, after looking at your mediate code, it seems like you might have another race condition?? I haven't thought about it, but ... In the file_open wrapper, in the middle, you restore the 'original' open, call the vector, and then return your wrapped_open into the vector. Again, for multiple threads, it seems to me like there would be a race, where the other threads might call the naked open vector instead of the wrapped one. I'll try to review this a bit more ... --linas From owner-lomac-users Tue May 15 14:21:56 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15963 Tue, 15 May 2001 14:21:42 -0400 (EDT) Date: Tue, 15 May 2001 13:26:56 -0500 To: Tim Fraser Cc: Linas Vepstas , lomac-users@lists.tislabs.com Subject: Re: three levels of security Message-ID: <20010515132656.B11023@backlot.linas.org> References: <20010514201142.A9251@backlot.linas.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from tfraser@tislabs.com on Tue, May 15, 2001 at 01:32:08PM -0400 From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 15, 2001 at 01:32:08PM -0400, Tim Fraser was heard to remark: > Hi! >=20 > > And then the lightbulb hit: how about 3 levels of security?=20 >=20 > Here's a brief description of it and its pros and cons from my upcoming > USENIX paper: >=20 > However, some user files had to remain at the unprotected lowest level > where programs that read from the lowest-level network interface, such > as E-mail agents and web browsers, could modify them. Consequently, > the three-level configuration was more visible to non-root users than > the two-level configuration, because it forced them to operate at > multiple levels. For example, it forced users to run separate text > editor processes for modifying lowest-level and middle-level files, > and to choose the proper editor depending on the situation. But here's a modification that fixes this problem: If a mid-level subject touches a low-level file object, it is *not* demoted. This allows mid-level users to operate more or less 'normally'. If a high or mid-level subject touches a network object, it is demoted to the lowest level. Thus, e.g. the mail delivery agents/subjects run at, and manipulate the lowest level objects, but a mid-level user can still read lowest-level email without demoting to the lowest level. Note that manipulating email with email programs would then allow=20 lowest-level objects to be promoted to the middle level. That=20 is, email programs operate as defacto a defacto 'lup'. Similarly, even the lowly /bin/cp could be used to promote a level-1 object to level 2 simply by copying. Just to over-emphasize: this behaviour does *not* protect against trojans introduced into the mid-level, since it allows users to=20 introduce trojans merely by copying. But it does shelter against=20 a broad class of network-based root-kits, and it still protects=20 the highest level against torjans, just as it does today. --linas --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7AXTwZKmaggEEWTMRAnG8AJ4gnRu9cI2aEaDb1tBCzxaiN2PjRQCeM6lU 8NfaNH/JVf5chxguocBrMCU= =beLp -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-lomac-users Tue May 15 14:24:27 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15989 Tue, 15 May 2001 14:24:25 -0400 (EDT) Date: Tue, 15 May 2001 13:29:39 -0500 To: Tim Fraser Cc: lomac-users@lists.tislabs.com Subject: Re: LOMAC bug on later 2.2 kernels Message-ID: <20010515132939.C11023@backlot.linas.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JP+T4n/bALQSJXh8" Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from tfraser@tislabs.com on Tue, May 15, 2001 at 01:11:14PM -0400 From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk --JP+T4n/bALQSJXh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 15, 2001 at 01:11:14PM -0400, Tim Fraser was heard to remark: > LOMAC v1.1.0 is known to work on 2.2.5 and 2.2.12. It's now known > not to work on 2.2.17 and 2.2.19. There must have been some change in the > kernel between 2.2.12 and 2.2.17 that LOMAC can't handle. I'm working on > fixing the bug now. works fine on 2.2.16 --linas --JP+T4n/bALQSJXh8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7AXWTZKmaggEEWTMRAl52AJsGS7nyCMASIgJRqqqTL5jPAwM7rQCfcQpD DBzGLRkZ14RHWlltglVdwrc= =Hh+x -----END PGP SIGNATURE----- --JP+T4n/bALQSJXh8-- From owner-lomac-users Tue May 15 14:30:44 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16022 Tue, 15 May 2001 14:30:37 -0400 (EDT) Date: Tue, 15 May 2001 13:35:51 -0500 To: Tim Fraser Cc: Linas Vepstas , lomac-users@lists.tislabs.com Subject: Re: pgrp problems Message-ID: <20010515133551.D11023@backlot.linas.org> References: <20010514231150.A9522@backlot.linas.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bu8it7iiRSEf40bY" Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from tfraser@tislabs.com on Tue, May 15, 2001 at 02:05:30PM -0400 From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk --Bu8it7iiRSEf40bY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 15, 2001 at 02:05:30PM -0400, Tim Fraser was heard to remark: > > improvements for LOMAC. It'll take me some time to fix the 2.2.17 bug and > the chroot bug. It's hard to predict how long these fixes will take, > especially with other work-related responsibilities getting in the way. = =20 > Hopefully, I'll put out fixes before the end of the month. The other email provides a very simple solution for the chroot/d_path=20 problem. I'll code it up and report how it goes. I'll send the patch=20 if it works (which I'm sure it will). --linas p.s. maybe the race described in the other note, with the replacement of the open wrappers with the originals, triggers the null files pointers ??? shot in the dark ... --Bu8it7iiRSEf40bY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7AXcHZKmaggEEWTMRAtcwAJ9vgxXvyUTptf3XuQWXMAHuV3Re9wCfYVPW PB9nV2bkzxtdUDHX2D1xmho= =cpMc -----END PGP SIGNATURE----- --Bu8it7iiRSEf40bY-- From owner-lomac-users Tue May 15 20:52:55 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA16661 Tue, 15 May 2001 20:52:44 -0400 (EDT) Date: Tue, 15 May 2001 20:57:37 -0400 (EDT) From: Timothy Fraser X-Sender: tfraser@clipper.gw.tislabs.com Reply-To: Timothy Fraser To: Linas Vepstas cc: lomac-users@lists.tislabs.com Subject: Re: chroot, again In-Reply-To: <20010515131413.A11023@backlot.linas.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! Thanks for your continued efforts to improve LOMAC! > This seems to have a race condition. If e.g. fs is shared between > multiple threads, and we're scheduled out right in the middle > of this call, then the other threads would see the wrong root. Since we're in the kernel, we don't have to worry about being scheduled out in the middle of a system call. The scheduler will run only if we call schedule() ourselves, directly, or indirectly by returning from the system call or doing something like blocking I/O. I'd like to avoid duplicating kernel code in the LKM whenever possible, just to keep things simple and make it easier to keep LOMAC current with kernel revisions. That being said, there may be multi-processor issues. Right now, LOMAC claims to work only on single-CPU systems. I'll probably wait for the community's hooks project (presently centered around lsm.immunix.org) to produce better kernel support for LOMAC before tackling multi-processor issues. > In the file_open wrapper, in the middle, you restore the 'original' open, > call the vector, and then return your wrapped_open into the vector. I'm not sure I understand... there are no function-pointer assignments in wrap_open(), just a call to *orig_open - a pointer that was set once during LOMAC initialization time. However, that's not to say that there are no bugs in wrap_open: I'm hunting one now in an attempt to get LOMAC running on later 2.2. kernels. By the way, thanks for verifying that LOMAC v1.1.0 works on 2.2.16 kernels. It must have been a change in 2.2.17 that LOMAC can't handle. - Tim From owner-lomac-users Tue May 15 21:02:46 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA16683 Tue, 15 May 2001 21:02:44 -0400 (EDT) Date: Tue, 15 May 2001 21:07:14 -0400 (EDT) From: Timothy Fraser X-Sender: tfraser@clipper.gw.tislabs.com To: Linas Vepstas cc: lomac-users@lists.tislabs.com Subject: Re: three levels of security In-Reply-To: <20010515132656.B11023@backlot.linas.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! > If a mid-level subject touches a low-level file object, it is *not* > demoted. This allows mid-level users to operate more or less > 'normally'. This scheme does provide useful protection, and makes sense given your preference to avoid compatibility problems by doing without Trojan horse protection. At this point, however, I'm inclined to keep LOMAC's Trojan horse protection feature until I find a case where it causes insurmountable compatibility problems. So far, I've been able to avoid conflicts by carefully configuring the PLM. In a few cases, I've had to bless some programs as "trusted". But it's worked acceptably so far. When LOMAC becomes configurable, however, the scheme you describe might make a good option. - Tim From owner-lomac-users Tue May 15 23:43:27 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA16949 Tue, 15 May 2001 23:43:16 -0400 (EDT) Date: Tue, 15 May 2001 22:48:29 -0500 To: Timothy Fraser Cc: Linas Vepstas , lomac-users@lists.tislabs.com Subject: Re: three levels of security Message-ID: <20010515224829.A11871@backlot.linas.org> References: <20010515132656.B11023@backlot.linas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from tfraser@tislabs.com on Tue, May 15, 2001 at 09:07:14PM -0400 From: linas@linas.org (Linas Vepstas) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id XAA16946 Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk On Tue, May 15, 2001 at 09:07:14PM -0400, Timothy Fraser was heard to remark: > Hi! > > > If a mid-level subject touches a low-level file object, it is *not* > > demoted. This allows mid-level users to operate more or less > > 'normally'. > > This scheme does provide useful protection, and makes sense given > your preference to avoid compatibility problems by doing without Trojan > horse protection. At this point, however, I'm inclined to keep LOMAC's > Trojan horse protection feature until I find a case where it causes ? I wasn't suggesting that you remove it. Right now, the default lomac config puts /home at level 1, offering no protection at all for the ordinary user. So what I propose doesn't weaken anything. (T reiterate: the new level 2 and 3 are merely a renaming of the current level 1 and 2, and thus preserves the relationships between them. A new, lower level 1 is introduced, and network-accessing subjects bounce to the new level 1.) What I fear is that if you make lomac easily configurable, users will unwittingly weaken the system by moving /home to high-level. Such a move removes the barrier between /usr, /etc and the ordinary joe-blow user. It also causes compatability problems for the ordinary user, as they struggle to manipulate level 1 email. This misconfiguration will give users the impression that lomac does *not* have a low compatiblity cost: it will result in a reputation for lomac as being 'intrusive'. To lower the compatibility cost, joe-average sysadmins will then mark mutt, elm, pine, etc. as 'trusted', further weakening the security. This is not what you want. > When LOMAC becomes configurable, however, the scheme you describe > might make a good option. As your paper points out, configurablity can be a bad thing: its all to easy to misconfigure because changes in configuration have subtle reprecussions. --linas From owner-lomac-users Wed May 16 00:35:17 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17123 Wed, 16 May 2001 00:35:15 -0400 (EDT) Date: Tue, 15 May 2001 23:40:29 -0500 To: Timothy Fraser Cc: Linas Vepstas , lomac-users@lists.tislabs.com Subject: Re: chroot, again Message-ID: <20010515234029.B11871@backlot.linas.org> References: <20010515131413.A11023@backlot.linas.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from tfraser@tislabs.com on Tue, May 15, 2001 at 08:57:37PM -0400 From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 15, 2001 at 08:57:37PM -0400, Timothy Fraser was heard to remar= k: > Hi! > =20 > Thanks for your continued efforts to improve LOMAC! That's the magic of the GPL -- guys like me just show up for the hell of it ... > > This seems to have a race condition. If e.g. fs is shared between > > multiple threads, and we're scheduled out right in the middle=20 > > of this call, then the other threads would see the wrong root. >=20 > Since we're in the kernel, we don't have to worry about being > scheduled out in the middle of a system call. The scheduler will run only > if we call schedule() ourselves, directly, or indirectly by returning from > the system call or doing something like blocking I/O.=20 Are you sure? Umm, hmm, I am not really an expert on this, but ... well, I *was* thinking that if an interrupt pops (timer, disk, net...) then=20 the bottom-half will run, and rescheduling occurs then. But a review of the kernel source shows that bottom halves only run when returning from a syscall. So it seems you're right ... but .. What if you page-fault, because some portion of the kernel that you need as been swapped out ... seems to me you'll reschedule=20 for sure... I am not convinced that rescheduling can't occur inside a system call. > I'd like to avoid duplicating kernel code in the LKM whenever > possible, just to keep things simple and make it easier to keep LOMAC > current with kernel revisions. Yes, I agree completely. But d_path is only a couple dozen lines of=20 code, quite small, and any other solution requires at least double or triple the number of lines of code ... > By the way, thanks for verifying that LOMAC v1.1.0 works on 2.2.16 > kernels. It must have been a change in 2.2.17 that LOMAC can't handle. Try diffing kerenls 2.2.16 and 2.2.17 to see what changed ... --linas --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7AgS9ZKmaggEEWTMRAtrDAJ4pUZc6hfeI7rUFODFlMM0hppaaHQCdEiWW W/ZNvOdketlLXSkkEmmsSU4= =8Jqw -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From owner-lomac-users Wed May 16 02:46:27 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA17483 Wed, 16 May 2001 02:46:23 -0400 (EDT) Date: Wed, 16 May 2001 01:51:38 -0500 To: lomac-users@lists.tislabs.com, tfraser@tislabs.com Subject: More craziness Message-ID: <20010516015138.A12199@backlot.linas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk OK, A report and some comments. First, I tried the d_path fix I talked about. It worked, sort-of. It suceeded in that lomac now seems to see the full path of the objects that a chrooted subject tries to access. Hurahh! However, it very mysteriously broke both of my chrooted daemons: both claimed that they could not find some files! Note: I have lomac NO_MEDIATION turned on, so that I would only get the lomac messages, without actualy having it 'do anything'. I can't begin to wonder how it is that this config could possibly break any subject, and in such a way! Any leads appreciated. ---------------------- Some new entries for lomac_plm.c: HIGHEST /var/spool/cron seems that vixie-cron (on redhat 6.2) looks in this directory for crontab files, instead of /etc like other crons. HIGHEST /var/www this is where debian thinks that web pages should go. Since you have already decided that /home/httpd is highest, then by extension, so should /var/www (although I still think this is wrong, and a 3 level system is needed). HIGHEST /var/log/syslog You already have /var/log/messages at highest; so syslog seems like a good idea too. HIGHEST /var/spool/postfix/usr HIGHEST /var/spool/postfix/lib HIGHEST /var/spool/postfix/etc These directories are meant to be postfix's chrooted shadows of 'the real thing', and thus qualify for being immutable. --------------- Bug ?? I notice that plm says HIGHEST /var/log/messages I am surprised to find that this puts *any* file starting with this path, e.g. /var/log/messages.offset, at level 2. This, of course, breaks some level-1 scripts that try to write /var/log/messages.offset This is unexpected behaviour, and I'd call it a bug. If a path indicates a file, then there should not be an implied wild-card at the end of it. ------------------ I don't understand why /var/log itself is marked highest, while childof is lowest. All that this seems to accomplish is to break some level-1 tools that want to create files in /var/log. I don't understand why you want to do this. General suggestion: document somewhere why you made this choice (and other the other plm choices). -- Linas Vepstas -- linas@gnumatic.com -- http://www.gnumatic.com/ From owner-lomac-users Wed May 16 08:54:05 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18341 Wed, 16 May 2001 08:53:56 -0400 (EDT) Date: Wed, 16 May 2001 08:58:05 -0400 (EDT) From: Timothy Fraser X-Sender: tfraser@clipper.gw.tislabs.com To: Linas Vepstas cc: lomac-users@lists.tislabs.com Subject: Re: chroot, again In-Reply-To: <20010515234029.B11871@backlot.linas.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! > Are you sure? Yeah, BSD works that way, too. In Linux, your thread may get hijacked in mid-syscall to handle one or more slow interrupts, but in these cases your thread gets to go back and finish the system call after it handles the interrupt(s). Once the system call is done, the thread ultimately calls schedule(). > What if you page-fault, because some portion of the kernel that > you need as been swapped out ... seems to me you'll reschedule > for sure... I am not convinced that rescheduling can't occur > inside a system call. Well, that can happen in some other kernels (like BSD), but in Linux, the kernel text is not paged. > Yes, I agree completely. But d_path is only a couple dozen lines of > code, quite small, and any other solution requires at least double or > triple the number of lines of code ... Even if you do the current->fs->root swap from my earlier message? > Try diffing kerenls 2.2.16 and 2.2.17 to see what changed ... OK, that's a good idea. - Tim From owner-lomac-users Wed May 16 09:09:10 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18376 Wed, 16 May 2001 09:08:57 -0400 (EDT) Date: Wed, 16 May 2001 09:13:20 -0400 (EDT) From: Timothy Fraser X-Sender: tfraser@clipper.gw.tislabs.com To: Linas Vepstas cc: lomac-users@lists.tislabs.com Subject: Re: More craziness In-Reply-To: <20010516015138.A12199@backlot.linas.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! > First, I tried the d_path fix I talked about. It worked, sort-of. Send me the code and I'll check it out once I've put out the various bug-related fires above it on my things-to-do list. > Some new entries for lomac_plm.c: Thanks! I'll try to integrate these into the next release. > Bug ?? > I notice that plm says > HIGHEST /var/log/messages > I am surprised to find that this puts *any* file starting with this path, > e.g. /var/log/messages.offset, at level 2. This, of course, breaks > some level-1 scripts that try to write /var/log/messages.offset > > This is unexpected behaviour, and I'd call it a bug. If a path > indicates a file, then there should not be an implied wild-card > at the end of it. Yes, that's a bug. It seems I forgot to list it in the BUGS file. Eventually, I'll implement some sort of * flag. Right now, * is the (unintended) default. I thought it was useful, because the PLM would set my old log files ("messages.1", "messages.2", etc.) to level 2. But, if it breaks some things, it'll have to be fixed (eventually). > I don't understand why /var/log itself is marked highest, while > childof is lowest. I didn't want to have a high file (messages) in a low directory. > General suggestion: document somewhere why you made this choice > (and other the other plm choices). Yeah, I have some notes. I should probably put together a more coherent description before I forget, myself. - Tim From owner-lomac-users Wed May 16 09:16:38 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18486 Wed, 16 May 2001 09:15:57 -0400 (EDT) Date: Wed, 16 May 2001 09:20:51 -0400 (EDT) From: Timothy Fraser X-Sender: tfraser@clipper.gw.tislabs.com To: Linas Vepstas cc: lomac-users@lists.tislabs.com Subject: Re: three levels of security In-Reply-To: <20010515224829.A11871@backlot.linas.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! > (T reiterate: the new level 2 and 3 are merely a renaming of the current > level 1 and 2, and thus preserves the relationships between them. > A new, lower level 1 is introduced, and network-accessing subjects > bounce to the new level 1.) OK, a 3-level configuration can provide better protection than a 2-level configuration. I balked only because I though you were proposing to turn off demotion between some subset of those 3 levels. > What I fear is that if you make lomac easily configurable, users > will unwittingly weaken the system by moving /home to high-level. These are valid concerns. I think I may be able to have the best of both worlds by providing a simple default policy, and documenting the configurability features as "for experts only", but who can say? In either case, configurability is pretty far down on my things-to-do list, so there's no need to decide any time soon. - Tim From owner-lomac-users Wed May 16 12:19:00 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19002 Wed, 16 May 2001 12:18:18 -0400 (EDT) Date: Wed, 16 May 2001 11:23:33 -0500 To: Timothy Fraser Cc: Linas Vepstas , lomac-users@lists.tislabs.com Subject: Re: More craziness Message-ID: <20010516112333.A13117@backlot.linas.org> References: <20010516015138.A12199@backlot.linas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from tfraser@tislabs.com on Wed, May 16, 2001 at 09:13:20AM -0400 From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk On Wed, May 16, 2001 at 09:13:20AM -0400, Timothy Fraser was heard to remark: > Hi! > > > First, I tried the d_path fix I talked about. It worked, sort-of. > > Send me the code and I'll check it out once I've put out the > various bug-related fires above it on my things-to-do list. attached below in readable and uuencoded format (so mailer doesn't scramble tabs). It contains new plm entries, and a slight change to logging as well as the d_path->lomac_d_path patch. > > I don't understand why /var/log itself is marked highest, while > > childof is lowest. > > I didn't want to have a high file (messages) in a low directory. duhh right. A cracker could potentially rename /var/log/messages to something else if this were'nt the case. --linas From owner-lomac-users Wed May 16 12:22:10 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19022 Wed, 16 May 2001 12:21:48 -0400 (EDT) Date: Wed, 16 May 2001 11:27:04 -0500 To: Timothy Fraser Cc: Linas Vepstas , lomac-users@lists.tislabs.com Subject: Re: chroot, again Message-ID: <20010516112704.B13117@backlot.linas.org> References: <20010515234029.B11871@backlot.linas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from tfraser@tislabs.com on Wed, May 16, 2001 at 08:58:05AM -0400 From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk On Wed, May 16, 2001 at 08:58:05AM -0400, Timothy Fraser was heard to remark: > > > What if you page-fault, because some portion of the kernel that > > you need as been swapped out ... seems to me you'll reschedule > > for sure... I am not convinced that rescheduling can't occur > > inside a system call. > > Well, that can happen in some other kernels (like BSD), but in > Linux, the kernel text is not paged. What about kernel data? Some page containing some dentry might get swapped out, or at least the page containing the dentry->name. --linas From owner-lomac-users Wed May 16 12:31:59 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19038 Wed, 16 May 2001 12:31:37 -0400 (EDT) Message-ID: <3B02663D.FD2A2118@woptura.com> Date: Wed, 16 May 2001 06:36:29 -0500 From: "J.D.K. Chipps" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4 i586) X-Accept-Language: en MIME-Version: 1.0 To: lomac-users@lists.tislabs.com Subject: How to unsub Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Sorry, I lost the instructions that came with my subscription. can someone help me? Thanks From owner-lomac-users Thu May 17 10:57:22 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21862 Thu, 17 May 2001 10:55:57 -0400 (EDT) Date: Thu, 17 May 2001 10:01:11 -0500 To: lomac-users@lists.tislabs.com, tfraser@tislabs.com Subject: Patch for chroot Message-ID: <20010517100111.A15461@backlot.linas.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline User-Agent: Mutt/1.3.17i From: linas@linas.org (Linas Vepstas) Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Below follows the patch I forgot to include previously. With this patch, chrooted programs appear to operate correctly on my system. The patch also includes one small change to how things are traced, and also, a number of new plm entries. I've attached the patch in plain text for readability, and uuencoded, for usability. ---------------- New bugs: -- first, an annoyance: The cvs pserver appearently tries to create /tmp very frequently. As a result, lomac prints a mediation error message that level 1 cvs can't modify level 2 / The syslog is flooded with these messages. =20 I'd love to just be able to eliminate this error message ... I'm contemplating a patch to detect existing directories, and just bail in such a case. But maybe this isn't really the 'right' thing to do? -- real bug: the collection of postfix mail handlers demote to=20 level-1, but end up holding level-2 pipes between each other.=20 I haven't investigated this more thoroughly just yet. --=20 Linas Vepstas -- linas@linas.org -- http://www.linas.org/ diff -r -u Lomac/Src/LKM/kernel_interface.c Lomac-linas/Src/LKM/kernel_inte= rface.c --- Lomac/Src/LKM/kernel_interface.c Fri Apr 6 12:26:29 2001 +++ Lomac-linas/Src/LKM/kernel_interface.c Wed May 16 00:15:05 2001 @@ -431,7 +431,7 @@ =20 if( p_object->d_name.name && p_object->d_name.name[ 0 ] !=3D '\0' ) { =20 - strncpy( path_s, d_path( (struct dentry *)p_object, path_s, bufflen ), + strncpy( path_s, lomac_d_path( (struct dentry *)p_object, path_s, buff= len ), bufflen ); /* the cast is to remove const */ return( 0 ); =20 diff -r -u Lomac/Src/LKM/kernel_lkm.c Lomac-linas/Src/LKM/kernel_lkm.c --- Lomac/Src/LKM/kernel_lkm.c Mon Apr 9 11:23:33 2001 +++ Lomac-linas/Src/LKM/kernel_lkm.c Mon May 14 18:32:54 2001 @@ -216,7 +216,7 @@ /* Set level of the process indicated by `p_proc'. */ set_subject_level( p_proc, LOMAC_HIGHEST_LEVEL ); =20 - if( verbose & VERBOSE_LOG_PGRPS ) { + if( verbose & VERBOSE_LOG_PGRP_ADJ ) { log_start(); log_append_string( "LOMAC/K: grandfathering " ); log_append_subject_id( p_proc ); diff -r -u Lomac/Src/LKM/kernel_util.c Lomac-linas/Src/LKM/kernel_util.c --- Lomac/Src/LKM/kernel_util.c Tue Apr 10 13:03:20 2001 +++ Lomac-linas/Src/LKM/kernel_util.c Wed May 16 14:39:59 2001 @@ -56,7 +56,7 @@ *=20 * When this function returns a valid dentry, it will increment * the dentry's reference count. The cal