From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzswing.ncsc.mil (jazzswing.ncsc.mil [144.51.68.65]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id i3C7AXRb006755 for ; Mon, 12 Apr 2004 03:10:33 -0400 (EDT) Received: from jazzswing.ncsc.mil (localhost [127.0.0.1]) by jazzswing.ncsc.mil with ESMTP id i3C78UUZ010860 for ; Mon, 12 Apr 2004 07:08:30 GMT Received: from omta10.mta.everyone.net (sitemail2.everyone.net [216.200.145.36]) by jazzswing.ncsc.mil with ESMTP id i3C78UmT010856 for ; Mon, 12 Apr 2004 07:08:30 GMT Date: Mon, 12 Apr 2004 15:10:07 +0800 Subject: Re: booting in enforcing mode Message-ID: MIME-Version: 1.0 (Generated by Pantomime 1.1.2) From: Rogelio Serrano To: russell@coker.com.au Cc: selinux@tycho.nsa.gov In-Reply-To: <200404121637.57839.russell@coker.com.au> Content-Type: text/plain; charset="us-ascii"; format="flowed" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On 2004-04-12 14:37:57 +0800 Russell Coker wrote: > On Sun, 11 Apr 2004 23:35, Rogelio Serrano > wrote: >>>> I rewrote mount, syslogd, and klogd to have the bare >>>> minimum priviledges. >>> >>> What did you change? >> >> Im using an lfs derived distro. it uses uClibc. >> >> These are all my own versions of those utilities. useful only >> from boot scripts. mount is just a wrapper around the mount >> syscall. and unmount also a wrapper around the unmount >> syscall. >> they dont need fstab or /proc/mounts. the original versions >> are >> causing too much noise in the logs. i was having lot of > > Reading a file of type etc_t is not going to do any great > harm. Almost > everything has read access to such files (think of all the > things that break > if /etc/passwd is not readable). > i see. im considering a config file for remount. thats what i call the mount replacement now. im very happy with the replacements actually. > If I made it a tunable for whether /proc/mounts and /etc/mtab > are accessible > would that satisfy your needs? I really want to keep everyone > on the same > policy tree as much as possible. That will allow you to > upgrade to newer > releases of SE Linux with less effort and also allow me to > incorporate any > improvements you make without any difficulty. > I think thats a good idea. I understand. Im going to download the policy snapshot from your website. I think its better than the default policy from selinux-usr. >> im using busybox for most of the network stuff and logging. in >> enforcing mode i was having a lot of difficulty to run syslogd >> in the proper context. > > You might want to read my previous messages on this topic to > this list, and > the paper I presented at OLS 2003 on running SE Linux on an > iPaQ. > >> i was having difficulty with the busybox code so i ripped out >> the relevant >> parts and built my own >> syslogd from that. same for klogd. i then tested these >> programs >> and took out some code that caused problems. > > My conclusion was that doing such things was best. I think > that having > syslogd and klogd running in different domains provides > minimal benefit and > for a small machine you might want to combine them (the policy > supports this > if you remove klogd.te). > Well klogd is reading from /proc kmsg and syslogd from /dev/log. I will need to keep them separate. The system is going to be used on both big and small "machines". This is in flux right now because i am studying runit, minit, quickinit and upstart. I want to combine the best features of these init implementations. The logging subsystem is going to be closely integrated with init. i particularly like quickinit and the supervision and logging concept of runit... >> One area im having a lot irritation with is the hotplug >> scripts. everytime they run bash opens /proc/kmem /dev/random >> /dev/pts /dev/ptmx and countless other devices and files that >> is not even mentioned anywhere in the relevant sources. now i >> dont know which to allow and which to deny. so now im going to >> write small prgrams to replace the scripts. > > Shell scripts always require access to more things than they > should. One > thing you might investigate is using a smaller shell than > bash. Shells with > less features request less access to the system... > im going to do that. im going to try minix shell, ash and pdksh. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.