From aleksey at nogin.org Sat May 1 17:56:27 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Sat, 01 May 2004 10:56:27 -0700 Subject: Need to allow output from processes under sudo. Message-ID: <4093E4CB.5070008@nogin.org> Recently sudo was changed back not to relabel the tty (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120213 , for example). This means that now the processes that sudo might run need to be given explicit access to the caller's tty (until something better is implemented - see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120213#c2 for my description of how I think it should work). Anyway, for now I had to add to my local policy modes: allow { checkpolicy_t consoletype_t ifconfig_t iptables_t ntpd_t load_policy_t sysadm_mail_t ping_t traceroute_t } staff_devpts_t:chr_file { getattr read write }; allow { locate_t sysadm_mail_t } staff_tmp_t:file { getattr write }; And this is probably still very incomplete. -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From mitch48 at sbcglobal.net Sun May 2 08:49:35 2004 From: mitch48 at sbcglobal.net (Tom Mitchell) Date: Sun, 2 May 2004 01:49:35 -0700 Subject: Access to cd device denied for cdp In-Reply-To: <1083199996.25352.5.camel@CirithUngol> References: <1083030774.18163.22.camel@CirithUngol> <408FD469.9040605@redhat.com> <1083199996.25352.5.camel@CirithUngol> Message-ID: <20040502084935.GB28091@xtl1.xtl.tenegg.com> On Wed, Apr 28, 2004 at 05:53:16PM -0700, Andrew Farris wrote: > From: Andrew Farris > > Andrew Farris wrote: > > > > >Playing a cd from the terminal using cdp, or cdplay (non-interactive), > > >results in the following avc in permissive mode (but the cd is allowed > > >to play): > > > > > >Apr 26 15:09:24 CirithUngol kernel: audit(1083017364.035:0): avc: > > >denied { ioctl } for pid=10129 exe=/usr/bin/cdp path=/dev/hdc dev=hdb8 > > >ino=66203 scontext=user_u:user_r:user_t > > >tcontext=system_u:object_r:fixed_disk_device_t tclass=blk_file > > > > > Please put in a bugzilla. The problem is that /dev/hdc is labeled > > wrong. > this is the solution. > brw-rw-rw-+ root disk system_u:object_r:removable_device_t /dev/hdc > > I will add this to bugzilla if not there already today. Should there be some distinctions for removable media eventually i.e "removable-rw-storage" or something reflecting a function.... USBflashstick, Floppy, iPod, tape, CDRW. Match this with "removable-ro-storage" for things like music CDs, iPod or other content in a "roach motel environment" where stuff might check in but never check out ;-). In the the iPod case policy could enforce read only. With hotplug hardware I can see disk controlers and other removable devices. I know I am splitting a hair... -- T o m M i t c h e l l /dev/null the ultimate in secure storage. From skywebsys at tiscali.it Sun May 2 11:19:42 2004 From: skywebsys at tiscali.it (skywebsy) Date: Sun, 02 May 2004 13:19:42 +0200 Subject: How to disable SELinux on FC2(Test3) Message-ID: <4094D94E.7030308@tiscali.it> as subject, thanks From hellcat at hispeed.ch Sun May 2 13:41:15 2004 From: hellcat at hispeed.ch (RJ) Date: Sun, 02 May 2004 15:41:15 +0200 Subject: How to disable SELinux on FC2(Test3) In-Reply-To: <4094D94E.7030308@tiscali.it> References: <4094D94E.7030308@tiscali.it> Message-ID: <4094FA7B.9010200@hispeed.ch> skywebsy wrote: > as subject, thanks > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > boot with kernel option 'selinux=0' --- RJ From russell at coker.com.au Sun May 2 16:45:39 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 3 May 2004 02:45:39 +1000 Subject: Policy file for 'aide' and/or 'tripwire'? In-Reply-To: <200404271752.i3RHqC8E015562@turing-police.cc.vt.edu> References: <200404271752.i3RHqC8E015562@turing-police.cc.vt.edu> Message-ID: <200405030245.39737.russell@coker.com.au> On Wed, 28 Apr 2004 03:52, Valdis.Kletnieks at vt.edu wrote: > Has anybody already done a policy file for Tripwire or its > open-sourced replacement 'aide'? Why not run it in the domain backup_t? Tripwire and backup programs both need read access to all files... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From rhally at mindspring.com Sun May 2 22:14:34 2004 From: rhally at mindspring.com (Richard Hally) Date: Sun, 02 May 2004 18:14:34 -0400 Subject: Core 2 SELinux installation In-Reply-To: <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> <40921EF5.7020207@234.cx> <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <409572CA.6030302@mindspring.com> Stephen Smalley wrote: > On Fri, 2004-04-30 at 05:40, Pete Chown wrote: > >>I think this is especially true for a new security technology. Most >>people's view of security is quite simplistic: they want the bad guys >>kept out, without their work being interfered with. If SELinux >>interferes with their work, they will turn it off, reasoning that normal >>Unix security has kept the bad guys out so far. They are then unlikely >>to try it again later however much people tell them that the policy has >>been improved. > > > So how would people feel about a separate relaxed policy that allows > everything in the system to run completely unconfined except for a small > set of specific services, e.g. apache, bind, postfix, ... > That would ensure that SELinux wouldn't get in the way of users, while > providing some protection benefit for network-facing services. > Another separate example policy would be very good. Additional different example policies would 1) demonstrate the flexibility on the concept and mechanism and 2) provide usage information that would useful in designing a better 'language' or higher level of abstraction. If there is an improved 'language', implementation and usage would be facilitated. Richard Hally From walters at redhat.com Sun May 2 22:49:11 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 02 May 2004 18:49:11 -0400 Subject: experimental relaxed policy Message-ID: <1083538151.2054.3.camel@nexus.verbum.private> Hi, There has been some work done on a "relaxed" policy. The intention of this policy is to simply protect system daemons, and not user logins. Right now there is just a policy for apache (which doesn't really work due to a kernel bug). Everything else runs in an "unconfined_t" domain, which essentially has every SELinux permission, and thus you are back to relying on DAC. But we'll be working on improving this policy. Right now the binary packages are called policy-relaxed and policy-relaxed-sources. This is likely to change. If you want to experiment with this, please see: http://people.redhat.com/~walters/selinux/ Again, much is likely to change, so you should basically only try this now if you are willing to help hack on it :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From walters at redhat.com Sun May 2 22:52:03 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 02 May 2004 18:52:03 -0400 Subject: experimental relaxed policy In-Reply-To: <1083538151.2054.3.camel@nexus.verbum.private> References: <1083538151.2054.3.camel@nexus.verbum.private> Message-ID: <1083538322.2054.7.camel@nexus.verbum.private> One important thing: You need to relabel your filesystem after installation! I suggest that if you are running the current strict policy you do this: setenforce 0 rpm -e policy{,-sources} rpm -Uvh /path/to/policy-relaxed*.rpm fixfiles relabel reboot fixfiles relabel Good luck, and please send bug reports here for now until we figure out how packaging is going to work (and thus what bugzilla product it will be). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 185 bytes Desc: This is a digitally signed message part URL: From tmolina at cablespeed.com Mon May 3 09:44:34 2004 From: tmolina at cablespeed.com (Thomas Molina) Date: Mon, 3 May 2004 05:44:34 -0400 (EDT) Subject: experimental relaxed policy In-Reply-To: <1083538151.2054.3.camel@nexus.verbum.private> References: <1083538151.2054.3.camel@nexus.verbum.private> Message-ID: On Sun, 2 May 2004, Colin Walters wrote: > Hi, > > There has been some work done on a "relaxed" policy. The intention of > this policy is to simply protect system daemons, and not user logins. > Right now there is just a policy for apache (which doesn't really work > due to a kernel bug). Everything else runs in an "unconfined_t" domain, > which essentially has every SELinux permission, and thus you are back to > relying on DAC. This sounds like a regression to me. Is this going to be instead of further development of the strict policy, or in addition to it? From sds at epoch.ncsc.mil Mon May 3 12:39:59 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 03 May 2004 08:39:59 -0400 Subject: experimental relaxed policy In-Reply-To: <1083538151.2054.3.camel@nexus.verbum.private> References: <1083538151.2054.3.camel@nexus.verbum.private> Message-ID: <1083587999.7446.53.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2004-05-02 at 18:49, Colin Walters wrote: > There has been some work done on a "relaxed" policy. The intention of > this policy is to simply protect system daemons, and not user logins. > Right now there is just a policy for apache (which doesn't really work > due to a kernel bug). Everything else runs in an "unconfined_t" domain, > which essentially has every SELinux permission, and thus you are back to > relying on DAC. IIRC, the problem with apache is simply upon restarting it from an admin shell; with the current policy, SELinux will close the descriptors to the admin tty, and apache misbehaves if descriptors 0-2 don't exist. We have a patch to the SELinux module to change it to re-open descriptors it closes upon exec to the null device to avoid such problems. But in the meantime, there are several options: 1) Change /etc/init.d/httpd to redirect descriptors 0-2 to /dev/null when starting httpd. 2) Remove noatsecure permission from initrc_t to the daemon domains in the daemon_base_domain macro in policy/macros/global_macros.te. This will cause glibc secure mode to be enabled upon the daemon execution, so that glibc will itself re-open descriptors 0-2 to /dev/null if they are closed (but will also cause glibc to perform other sanitization that may not be appropriate). 3) Allow httpd_t to access the tty/pty; not good for production use, but ok for experimentation with the policy, e.g.: allow httpd_t { tty_device_t devpts_t }:chr_file rw_file_perms; -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon May 3 14:13:15 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 May 2004 10:13:15 -0400 Subject: Problem with Tresys tools on Core 2 In-Reply-To: <200404301422.i3UEMhJx024372@gotham.columbia.tresys.com> References: <200404301422.i3UEMhJx024372@gotham.columbia.tresys.com> Message-ID: <4096537B.5070404@redhat.com> Karl MacMillan wrote: >>Nick, >> >>Seuser looks for the policy.conf file in /etc/security/selinux/src by >>default, but it seems that some systems only have the policy.conf file in >>/etc/security/selinux/src/policy (note the extra policy directory at the >>end). If that is the case on your system, in the file >>/usr/share/setools/seuser.conf change the line: >> >>policy.conf /etc/security/selinux/src/policy.conf >> >>to >> >>policy.conf /etc/security/selinux/src/policy/policy.conf >> >> >>On my Fedora Core 2 test 2 system the policy.conf is in both locations - >>anyone know which is the location for default installs of Fedora Core 2? >> >> >> > >Steve Smalley reminded me that this change of location was discussed a while >ago. We will change the default location for seuser for the next release, >but until then this change will need to be made to the configuration file. >Dan, any way to get this minor update made to the redhat packages? > > > setools-1.3-2 has this fix in it. And should be out on rawhide and in fc2-test3. >Karl > >Karl MacMillan >Tresys Technology >http://www.tresys.com >(410)290-1411 ext 134 > > > >>Karl >> >>Karl MacMillan >>Tresys Technology >>http://www.tresys.com >>(410)290-1411 ext 134 >> >> >> >>>-----Original Message----- >>>From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux- >>> >>> >>list- >> >> >>>bounces at redhat.com] On Behalf Of Nick >>>Sent: Thursday, April 29, 2004 7:10 PM >>>To: fedora-selinux-list at redhat.com >>>Subject: Re: Problem with Tresys tools on Core 2 >>> >>>On Thu, 2004-04-29 at 13:10, Nick wrote: >>> >>> >>>>Conditions: >>>>----------- >>>> >>>>Install from DVD ISO >>>>yum upgrade >>>>installation of RPMS >>>> checkpolicy-1.10-1.i386.rpm >>>> policy-sources-1.11.2-18.noarch.rpm >>>> setools-1.3-2.i386.rpm >>>> setools-gui-1.3-2.i386.rpm >>>> >>>> >>>>Results >>>>------- >>>> >>>>[root at rocket policy]# seinfo -r >>>>Could not open policy! >>>> >>>> >>>I rebuilt and now seinfo -r works. >>> >>> >>> >>>>[root at rocket policy]# seuser -X >>>>Error in StartScript (/usr/share/setools/se_user.tcl): >>>> >>>> >>>This still does not work >>> >>> >>> >>>>Thanks Nick >>>> >>>> >>>-- >>>Nick Gray >>>Senior Systems Engineer >>>Bruzenak Inc. >>>nagray at austin.rr.com >>>(512) 331-7998 >>> >>>-- >>>fedora-selinux-list mailing list >>>fedora-selinux-list at redhat.com >>>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> >>> >>-- >>fedora-selinux-list mailing list >>fedora-selinux-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> > > > From dwalsh at redhat.com Mon May 3 14:48:05 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 May 2004 10:48:05 -0400 Subject: experimental relaxed policy In-Reply-To: References: <1083538151.2054.3.camel@nexus.verbum.private> Message-ID: <40965BA5.9030801@redhat.com> Thomas Molina wrote: >On Sun, 2 May 2004, Colin Walters wrote: > > > >>Hi, >> >>There has been some work done on a "relaxed" policy. The intention of >>this policy is to simply protect system daemons, and not user logins. >>Right now there is just a policy for apache (which doesn't really work >>due to a kernel bug). Everything else runs in an "unconfined_t" domain, >>which essentially has every SELinux permission, and thus you are back to >>relying on DAC. >> >> > >This sounds like a regression to me. Is this going to be instead of >further development of the strict policy, or in addition to it? > > We are having talks now and are investigating how we can support both a strict and relaxed policy. Nothing formal has been decided. One of the goals is to figure out how we can have one policy(te) file shared between them that will work for both. I don't want to end up with and apache-strict.te and an apache-relaxed.te. But this is probably a matter of tunables within the policy file. One of the things we are considering is limiting the number of daemons we will lock down. We have picked out an arbitrary number of 5 for now and are trying to figure out which are the 5 daemons we would like to put in relaxed policy. My ideas are apache bind sendmail ftp ssh??? (Not sure this one is worth securing). I would like to have other comments on what which daemons should be in the first version of Relaxed policy. We hope to have something out this week. Dan >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From Valdis.Kletnieks at vt.edu Mon May 3 18:02:54 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 03 May 2004 14:02:54 -0400 Subject: Policy file for 'aide' and/or 'tripwire'? In-Reply-To: Your message of "Mon, 03 May 2004 02:45:39 +1000." <200405030245.39737.russell@coker.com.au> References: <200404271752.i3RHqC8E015562@turing-police.cc.vt.edu> <200405030245.39737.russell@coker.com.au> Message-ID: <200405031802.i43I2sw2001668@turing-police.cc.vt.edu> On Mon, 03 May 2004 02:45:39 +1000, Russell Coker said: > On Wed, 28 Apr 2004 03:52, Valdis.Kletnieks at vt.edu wrote: > > Has anybody already done a policy file for Tripwire or its > > open-sourced replacement 'aide'? > > Why not run it in the domain backup_t? Tripwire and backup programs both need > read access to all files.. Good hint - I'll have to chase that. Looks like it's almost but not quite what I want - looks like a few lines of tweaking should suffice (I'm pretty sure that can_network can be heaved over the side of the .te file, and I need other directories labeled with backup_store_t in the .fc file). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From rhallyx at mindspring.com Mon May 3 20:28:10 2004 From: rhallyx at mindspring.com (Richard Hally) Date: Mon, 03 May 2004 16:28:10 -0400 Subject: avc denied messages from setfiles Message-ID: <4096AB5A.2050205@mindspring.com> Below are some avc denied messages produced from running "fixfiles restore" in enforcing mode with updated policy-1.11.2-21. Richard Hally May 2 14:38:19 localhost kernel: audit(1083523099.396:0): avc: denied { getattr } for pid=31565 exe=/usr/sbin/setfiles path=/var/named/chroot/var/named/chroot/dev/null dev=hdc3 ino=2453550 scontext=root:sysadm_r:setfiles_t tcontext=system_u:object_r:named_conf_t tclass=chr_file May 2 14:38:19 localhost kernel: audit(1083523099.397:0): avc: denied { getattr } for pid=31565 exe=/usr/sbin/setfiles path=/var/named/chroot/var/named/chroot/dev/null dev=hdc3 ino=2453550 scontext=root:sysadm_r:setfiles_t tcontext=system_u:object_r:named_conf_t tclass=chr_file May 2 14:38:19 localhost kernel: audit(1083523099.397:0): avc: denied { getattr } for pid=31565 exe=/usr/sbin/setfiles path=/var/named/chroot/var/named/chroot/dev/random dev=hdc3 ino=2453551 scontext=root:sysadm_r:setfiles_t tcontext=system_u:object_r:named_conf_t tclass=chr_file May 2 14:38:19 localhost kernel: audit(1083523099.398:0): avc: denied { getattr } for pid=31565 exe=/usr/sbin/setfiles path=/var/named/chroot/var/named/chroot/dev/random dev=hdc3 ino=2453551 scontext=root:sysadm_r:setfiles_t tcontext=system_u:object_r:named_conf_t tclass=chr_file From russell at coker.com.au Mon May 3 21:27:44 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 4 May 2004 07:27:44 +1000 Subject: Policy file for 'aide' and/or 'tripwire'? In-Reply-To: <200405031802.i43I2sw2001668@turing-police.cc.vt.edu> References: <200404271752.i3RHqC8E015562@turing-police.cc.vt.edu> <200405030245.39737.russell@coker.com.au> <200405031802.i43I2sw2001668@turing-police.cc.vt.edu> Message-ID: <200405040727.44433.russell@coker.com.au> On Tue, 4 May 2004 04:02, Valdis.Kletnieks at vt.edu wrote: > On Mon, 03 May 2004 02:45:39 +1000, Russell Coker said: > > On Wed, 28 Apr 2004 03:52, Valdis.Kletnieks at vt.edu wrote: > > > Has anybody already done a policy file for Tripwire or its > > > open-sourced replacement 'aide'? > > > > Why not run it in the domain backup_t? Tripwire and backup programs both > > need read access to all files.. > > Good hint - I'll have to chase that. Looks like it's almost but not quite > what I want - looks like a few lines of tweaking should suffice (I'm pretty > sure that can_network can be heaved over the side of the .te file, and I > need other directories labeled with backup_store_t in the .fc file). However a tripwire program that sends md5 checksums over the wire could be handy. If there are standard locations for the tripwire database and binaries then let me know and I'll add them to the policy. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From mitch48 at sbcglobal.net Mon May 3 22:16:39 2004 From: mitch48 at sbcglobal.net (Tom Mitchell) Date: Mon, 3 May 2004 15:16:39 -0700 Subject: Core 2 SELinux installation In-Reply-To: <1083333831.30875.74.camel@moss-spartans.epoch.ncsc.mil> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> <40921EF5.7020207@234.cx> <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> <1083331471.4710.2.camel@rivendell.local.net> <1083333831.30875.74.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20040503221639.GA18439@xtl1.xtl.tenegg.com> On Fri, Apr 30, 2004 at 10:03:51AM -0400, Stephen Smalley wrote: > On Fri, 2004-04-30 at 09:24, Jeremy Katz wrote: > > I think (consistent with my view a few months ago :-) that this is a > > very good idea. At the same time, it's something that's clearly not > > realistic to target for FC2 since the last test release just went out > > and so it'd be going out with very little testing. > > That's fine; it can always be introduced post-FC2. It matters little > for FC2 given that SELinux will be disabled by default for it anyway. Yes a small focused policy is a good thing and much better than apparently inviting people to boot with SELinux off. This would keep the security checking code paths active, but with a minimum list of things to check the impact would be minimized. This includes syslog noise as well. A minimized policy would remove much demand to remove or hobble the kernel side mechanism and minimize any divergence that developers might wish to introduce. I happen to like the current effort to "classify everything" but this is a big task. Since not all packages that folks like to use pass through RH hands the task is almost unbounded. -- T o m M i t c h e l l /dev/null the ultimate in secure storage. From tmolina at cablespeed.com Mon May 3 22:16:57 2004 From: tmolina at cablespeed.com (Thomas Molina) Date: Mon, 3 May 2004 18:16:57 -0400 (EDT) Subject: experimental relaxed policy In-Reply-To: <40965BA5.9030801@redhat.com> References: <1083538151.2054.3.camel@nexus.verbum.private> <40965BA5.9030801@redhat.com> Message-ID: > >>There has been some work done on a "relaxed" policy. The intention of > >>this policy is to simply protect system daemons, and not user logins. > >>Right now there is just a policy for apache (which doesn't really work > >>due to a kernel bug). Everything else runs in an "unconfined_t" domain, > >>which essentially has every SELinux permission, and thus you are back to > >>relying on DAC. > > One of the things we are considering is limiting the number of daemons > we will lock down. We have picked out > an arbitrary number of 5 for now and are trying to figure out which are > the 5 daemons we would like to put in relaxed policy. > > My ideas are > > apache > bind > sendmail > ftp > ssh??? (Not sure this one is worth securing). I am apparently not expressing myself well. My point is that if we are relaxing policy to the point where you are relying on DAC, what is the point? I want to test strict policy on those things where it most makes a difference. In that vein, sendmail and bind are two which have historically had a lot of problems. I would think those would be candidates for stricter policy, not more permissive. From smoogen at lanl.gov Mon May 3 22:29:26 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Mon, 03 May 2004 16:29:26 -0600 Subject: experimental relaxed policy In-Reply-To: References: <1083538151.2054.3.camel@nexus.verbum.private> <40965BA5.9030801@redhat.com> Message-ID: <1083623365.12922.3.camel@smoogen3.lanl.gov> On Mon, 2004-05-03 at 16:16, Thomas Molina wrote: > > >>There has been some work done on a "relaxed" policy. The intention of > > >>this policy is to simply protect system daemons, and not user logins. > > >>Right now there is just a policy for apache (which doesn't really work > > >>due to a kernel bug). Everything else runs in an "unconfined_t" domain, > > >>which essentially has every SELinux permission, and thus you are back to > > >>relying on DAC. > > > > One of the things we are considering is limiting the number of daemons > > we will lock down. We have picked out > > an arbitrary number of 5 for now and are trying to figure out which are > > the 5 daemons we would like to put in relaxed policy. > > > > My ideas are > > > > apache > > bind > > sendmail > > ftp > > ssh??? (Not sure this one is worth securing). > > I am apparently not expressing myself well. My point is that if we are > relaxing policy to the point where you are relying on DAC, what is the > point? I want to test strict policy on those things where it most makes a > difference. In that vein, sendmail and bind are two which have > historically had a lot of problems. I would think those would be > candidates for stricter policy, not more permissive. I think you are in violent agreement in some ways. Selinux people are looking to write policies that lock down a small set of daemons (sendmail/bind/apache/ftp/portmap) but have user space and other items to end up with a permissive policy until wrinkles can be ironed out. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From Valdis.Kletnieks at vt.edu Mon May 3 23:22:56 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 03 May 2004 19:22:56 -0400 Subject: experimental relaxed policy In-Reply-To: Your message of "Mon, 03 May 2004 18:16:57 EDT." References: <1083538151.2054.3.camel@nexus.verbum.private> <40965BA5.9030801@redhat.com> Message-ID: <200405032322.i43NMucs012157@turing-police.cc.vt.edu> On Mon, 03 May 2004 18:16:57 EDT, Thomas Molina said: > I am apparently not expressing myself well. My point is that if we are > relaxing policy to the point where you are relying on DAC, what is the > point? I want to test strict policy on those things where it most makes a > difference. In that vein, sendmail and bind are two which have > historically had a lot of problems. I would think those would be > candidates for stricter policy, not more permissive. I think the intent was "these 5 will be subject to strict policy, but we won't worry about *other* stuff, which will be more relaxed". So it isn't that sendmail and bind would be less relaxed, it would be things like 'hwclock' and 'ping' that would have the relaxed policy. So instead of 460 .te files (like policy-sources-1.11.2-18 has), we'd trim it down to the "top 10" and then one catch-all policy. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From mitch48 at sbcglobal.net Tue May 4 00:36:30 2004 From: mitch48 at sbcglobal.net (Tom Mitchell) Date: Mon, 3 May 2004 17:36:30 -0700 Subject: How to disable SELinux on FC2(Test3) In-Reply-To: <4094FA7B.9010200@hispeed.ch> References: <4094D94E.7030308@tiscali.it> <4094FA7B.9010200@hispeed.ch> Message-ID: <20040504003630.GB18439@xtl1.xtl.tenegg.com> On Sun, May 02, 2004 at 03:41:15PM +0200, RJ wrote: > skywebsy wrote: > > >as subject, thanks ... > boot with kernel option 'selinux=0' Currently there are two boot time kernel variables of interest in this regard: enforcing selinux If you are testing then most will want to toggle enforcing on(1) or off(0). In your /boot/grub/grub.conf look for a line much like this: kernel /vmlinuz-2.6.5-1.327 ro root=LABEL=/ enforcing=1 vdso=0 acpi=off With enforcing off you can still see in /var/log/messages the access errors (avc) and be able to explore the whole set of SELinux concepts. If you suspect that SELinux is getting in the way of an application it can be controlled dynamically. As root first change context: newrole -r sysadm_r Then id will return context=root:sysadm_r:sysadm_t something like this: # id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),\ 4(adm),6(disk),10(wheel) context=root:sysadm_r:sysadm_t Now to toggle enforcing: logger "Turning Enforcing OFF" echo "0" > /selinux/enforce logger "Enforcing is OFF" The "logger" lines let you mark sections in /var/log/messages that are interesting to people building the policy files. i.e. You can do stuff like... logger "Testing something I think is broken by policy restrictions........" logger "Start Testing ...................................................." # launch application logger "End Testing ...................................................." logger "Turning Enforcing OFF" echo "0" > /selinux/enforce logger "Enforcing is OFF" logger "Testing something I think is broken by policy restrictions........" logger "Start Testing ...................................................." # launch application logger "End Testing ...................................................." logger "Turning Enforcing back On" echo "1" > /selinux/enforce logger "Enforcing is back On" Some testers may wish to set selinux=0 and not load the kernel security module at all. I guess that this needs to be done too; people will do it. kernel /vmlinuz-2.6.5-1.327 ro root=LABEL=/ selinux=0 vdso=0 acpi=off I am sure I missed something .... -- T o m M i t c h e l l /dev/null the ultimate in secure storage. From mitch48 at sbcglobal.net Tue May 4 00:51:30 2004 From: mitch48 at sbcglobal.net (Tom Mitchell) Date: Mon, 3 May 2004 17:51:30 -0700 Subject: Policy file for 'aide' and/or 'tripwire'? In-Reply-To: <200405040727.44433.russell@coker.com.au> References: <200404271752.i3RHqC8E015562@turing-police.cc.vt.edu> <200405030245.39737.russell@coker.com.au> <200405031802.i43I2sw2001668@turing-police.cc.vt.edu> <200405040727.44433.russell@coker.com.au> Message-ID: <20040504005130.GC18439@xtl1.xtl.tenegg.com> On Tue, May 04, 2004 at 07:27:44AM +1000, Russell Coker wrote: .... > If there are standard locations for the tripwire database and binaries then > let me know and I'll add them to the policy. The below should be a fair start: # rpm -qa | grep trip tripwire-2.3.1-17 ======== # rpm -q --list tripwire-2.3.1-17 /etc/cron.daily/tripwire-check /etc/tripwire /etc/tripwire/twcfg.txt /etc/tripwire/twinstall.sh /etc/tripwire/twpol.txt /usr/sbin/siggen /usr/sbin/tripwire /usr/sbin/twadmin /usr/sbin/twprint /usr/share/doc/tripwire-2.3.1 /usr/share/doc/tripwire-2.3.1/COPYING /usr/share/doc/tripwire-2.3.1/ChangeLog /usr/share/doc/tripwire-2.3.1/README /usr/share/doc/tripwire-2.3.1/README.RPM /usr/share/doc/tripwire-2.3.1/Release_Notes /usr/share/doc/tripwire-2.3.1/TRADEMARK /usr/share/doc/tripwire-2.3.1/policyguide.txt /usr/share/doc/tripwire-2.3.1/quickstart.gif /usr/share/doc/tripwire-2.3.1/quickstart.txt /usr/share/man/man4/twconfig.4.gz /usr/share/man/man4/twpolicy.4.gz /usr/share/man/man5/twfiles.5.gz /usr/share/man/man8/siggen.8.gz /usr/share/man/man8/tripwire.8.gz /usr/share/man/man8/twadmin.8.gz /usr/share/man/man8/twintro.8.gz /usr/share/man/man8/twprint.8.gz /var/lib/tripwire /var/lib/tripwire/report ======== # cat /tmp/trip-stuff edited from "locate tripwire" /var/lib/tripwire /var/lib/tripwire/report /var/lib/tripwire/report/xtl2.xtl.tenegg.com-20040303-172709.twr .... /var/lib/tripwire/report/xtl2.xtl.tenegg.com-20040502-044143.twr /var/lib/tripwire/report /var/lib/tripwire/xtl2.xtl.tenegg.com.twd /var/lib/tripwire/xtl2.xtl.tenegg.com.twd.bak /var/lib/tripwire /etc/cron.daily/tripwire-check /etc/tripwire /etc/tripwire/twinstall.sh /etc/tripwire/twcfg.txt /etc/tripwire/site.key /etc/tripwire/twpol.txt /etc/tripwire/tw.cfg /etc/tripwire/tw.pol /etc/tripwire/tw.cfg.5383.bak /etc/tripwire/tw.pol.bak /etc/tripwire/xtl2.xtl.tenegg.com-local.key /etc/tripwire/tw.cfg.1891.bak /etc/tripwire /usr/sbin/tripwire -- T o m M i t c h e l l /dev/null the ultimate in secure storage. From jmorris at redhat.com Tue May 4 05:13:45 2004 From: jmorris at redhat.com (James Morris) Date: Tue, 4 May 2004 01:13:45 -0400 (EDT) Subject: experimental relaxed policy In-Reply-To: Message-ID: On Mon, 3 May 2004, Thomas Molina wrote: > > an arbitrary number of 5 for now and are trying to figure out which are > > the 5 daemons we would like to put in relaxed policy. > > > > My ideas are > > > > apache > > bind > > sendmail > > ftp > > ssh??? (Not sure this one is worth securing). > > I am apparently not expressing myself well. My point is that if we are > relaxing policy to the point where you are relying on DAC, what is the > point? I want to test strict policy on those things where it most makes a > difference. In that vein, sendmail and bind are two which have > historically had a lot of problems. I would think those would be > candidates for stricter policy, not more permissive. There is a bit of confusion here, totally understandable. The daemons referred to above are candidates for being strictly controlled. The term 'relaxed policy' here refers to the concept of providing very strict policies for a small, critical subset of the system, then allowing the rest of the system to be unconfined. It's relaxed in terms of not trying to provide strict policies for every domain. - James -- James Morris From philpar at swfla.rr.com Tue May 4 12:58:14 2004 From: philpar at swfla.rr.com (Phil Parsons) Date: Tue, 04 May 2004 08:58:14 -0400 Subject: experimental relaxed policy In-Reply-To: References: Message-ID: <40979366.8020105@swfla.rr.com> An HTML attachment was scrubbed... URL: From russell at coker.com.au Tue May 4 15:50:03 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 5 May 2004 01:50:03 +1000 Subject: avc denied messages from setfiles In-Reply-To: <4096AB5A.2050205@mindspring.com> References: <4096AB5A.2050205@mindspring.com> Message-ID: <200405050150.03602.russell@coker.com.au> On Tue, 4 May 2004 06:28, Richard Hally wrote: > Below are some avc denied messages produced from running "fixfiles > restore" in enforcing mode with updated policy-1.11.2-21. The attached policy should fix that. It will be in rawhide in a couple of days. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- #DESC Setfiles - SELinux filesystem labeling utilities # # Authors: Russell Coker # X-Debian-Packages: policycoreutils # ################################# # # Rules for the setfiles_t domain. # # setfiles_exec_t is the type of the setfiles executable. # # needs auth_write attribute because it has relabelfrom/relabelto # access to shadow_t type setfiles_t, domain, privlog, privowner, auth_write; type setfiles_exec_t, file_type, sysadmfile, exec_type; role system_r types setfiles_t; role sysadm_r types setfiles_t; allow setfiles_t initrc_devpts_t:chr_file { read write ioctl }; allow setfiles_t { ttyfile ptyfile tty_device_t admin_tty_type }:chr_file { read write ioctl }; domain_auto_trans(sysadm_t, setfiles_exec_t, setfiles_t) allow setfiles_t { userdomain privfd initrc_t init_t }:fd use; uses_shlib(setfiles_t) allow setfiles_t self:capability { dac_override dac_read_search }; # for upgrading glibc and other shared objects - without this the upgrade # scripts will put things in a state such that setfiles can not be run! allow setfiles_t lib_t:file { read execute }; # Get security policy decisions. can_getsecurity(setfiles_t) r_dir_file(setfiles_t, { policy_src_t policy_config_t }) allow setfiles_t file_type:dir r_dir_perms; allow setfiles_t { file_type unlabeled_t }:dir_file_class_set { getattr relabelfrom }; allow setfiles_t file_type:{ dir file lnk_file sock_file fifo_file } relabelto; allow setfiles_t unlabeled_t:dir read; allow setfiles_t device_type:{ chr_file blk_file } relabelto; allow setfiles_t device_t:{ chr_file blk_file } { getattr relabelfrom read }; allow setfiles_t { ttyfile ptyfile }:chr_file getattr; allow setfiles_t fs_t:filesystem getattr; allow setfiles_t fs_type:dir r_dir_perms; allow setfiles_t etc_runtime_t:file read; allow setfiles_t etc_t:file read; allow setfiles_t proc_t:file { getattr read }; dontaudit setfiles_t proc_t:lnk_file { getattr read }; # for config files in a home directory allow setfiles_t home_type:file r_file_perms; dontaudit setfiles_t sysadm_tty_device_t:chr_file { relabelfrom }; From fedora at andrewfarris.com Tue May 4 18:17:00 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Tue, 04 May 2004 11:17:00 -0700 Subject: nVIDIA binary driver audits generated by OpenGL apps In-Reply-To: <1083284472.22563.19.camel@CirithUngol> References: <1083029984.18163.9.camel@CirithUngol> <408FD08B.9030000@redhat.com> <1083189918.30567.14.camel@CirithUngol> <40910118.8060900@redhat.com> <1083284472.22563.19.camel@CirithUngol> Message-ID: <1083694620.22380.7.camel@CirithUngol> Just to report in, policy-1.11.2-21 manages the /dev/nvidia* devices without further changes for OpenGL to run as normal user in enforcing mode, thanks. -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lmorgul on irc.freenode.net "The only thing necessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From bobgus at rcn.com Tue May 4 19:50:17 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Tue, 4 May 2004 14:50:17 -0500 Subject: Humpty Dumpty Message-ID: I have newly arrived at the dangerous stage of SElinux testing - and have a few questions. Some recent history: Yesterday I downloaded some of the SELinux tool stuff and rebuilt it from the SRPMS. (This may not have been necessary). I was able to get the apol application up and running (but I think I need glasses - font size is a bit small) [- rich, thin, big enough screen] The application 'seuser' did not seem to be able to find the policy.conf file. I found the .tcl file and hacked a bit on that, but tcl is not a native language for me. (Today I found the /usr/share/setools/seuser.conf file with the missing 'policy' in the policy.conf path) Also there was something about the file_contexts - it was a file instead of a directory at one point - so I deleted the file and redid some steps and found a populated directory afterwards - so I must have done something (correctly?). [Sorry about the lack of specifics - I was just playing around - thinking that I would probably have to do it over again later - once I knew what I was doing] ------ Then I found an application 'System Settings -> Security Level' With this tool, I could turn my firewall on and also turn on something in SELinux. The SELinux button said 'Active'. I clicked on it and saw options 'Warn' and 'Disabled'. Then I went back to the Firewall settings and decided not to do anything there. Clicking the OK button at the bottom gave me a dialog box - something about 'do you want security to be on'. Since I thought security was already on, I clicked on yes... It was soon after that I attempted to 'su' -- and found out that I could not. This was (fortunately) not a production system. Even though I knew that Humpty had fallen off the wall, I figured that after a reboot - the problems would go away. Not. The reboot only progressed about half way. There were extra messages on the console screen. (This message repeated 63067847 times...) The messages stopped. I was concerned that the log files had filled up the remaining 35G of disk space. I hit the power switch. I mounted the root SCSI disk on another (non SELinux) system and saw the file: [root at hoho2 sysconfig]# pwd /etc/sysconfig [root at hoho2 sysconfig]# cat system-config-securitylevel # Configuration file for system-config-securitylevel --enabled [root at hoho2 sysconfig]# I went in with vim and changed the last line to read '--disabled' and then attempted to reboot the SELinux enabled system. No go - there was still something set that was preventing me from booting. I did not even get far enough to try to log on. ----- Fortunately, I had printed out some of the SELinux documentation (printed out, not read as yet). I noticed an email message from Hannes Mayer saying to pass 'selinux=0' to grub at boot time. This I did, and wonderfully my system booted up. It did not even have the pesky extra error messages which I had noticed for awhile when booting my running system - 'avc denied', etc. Reading a bit more of the email archive this morning, particularly the helpful message from Tom Mitchell - Mon, 3 May 2004 17:36:30 -0700 I went into grub.conf and added 'enforcing=0 selinux=1' to the kernel line and then rebooted. Success - it looks like things are back to the point where I can do more testing. My immediate objective is to configure things so that I can turn enforcing on and successfully boot my system. Maybe this is not yet possible (not enough file_contexts set?). A lesser goal would be to dynamically set and (hopefully) unset the enforcing parameter as mentioned later in Tom Mitchell's timely and very helpful email message - and then see what problems develop - in a (hopefully) controlled environment. Questions: What versions of what software are currently SElinux enabled. I have rpm 4.3.1 - does that rpm do the right thing as far as installing the extra file contexts? What happens if I do an up2date. Will I load in non-SELinux programs which will undo everything learned up to that point? [I have FC2(Test3) installed and updated to the point where there are no more updates available - and this is with a few extra 'source' paths] How do I determine whether essential programs are still SELinux enabled? What is rawhide? Is that a collection of setools? (or an ancient Fedora image?) (I would like to creep up on the concept of SecurityEnabled with lots of log messages, but not too many.. :-) ) How can I make the file context messages go away -correctly- (i.e., by setting the file contexts)? Is there a mass process that will tweek all files? Fedora Core release 1.92 (FC2 Test 3) Kernel 2.6.5-1.327custom on an i686 hoho2 login: user1 Password: Last login: Tue May 4 10:41:38 from TZ [user1 at hoho2 user1]$ su Password: audit(1083685732.396:0): avc: denied { transition } for pid=2176 exe=/bin/su path=/bin/bash dev=sda2 ino=2605063 scontext=user_u:sysadm_r:sysadm_t tcontext=r oot:sysadm_r:sysadm_t tclass=process I can guess that something is objectionable here, but see below when I did it again [root at hoho2 user1]# exit [user1 at hoho2 user1]$ date Tue May 4 10:50:49 CDT 2004 [user1 at hoho2 user1]$ su Password: [root at hoho2 user1]# See, here I did another su, but did not get log messages. Why? .. .. Could someone comment on the 'meaning' of some of these log messages (the SELinux generated ones - the other lines are left for context. [root at hoho2 sysconfig]# date Tue May 4 10:54:45 CDT 2004 [root at hoho2 sysconfig]# tail /var/log/messages May 4 10:48:33 hoho2 messagebus: messagebus startup succeeded May 4 10:48:44 hoho2 login(pam_unix)[2136]: session opened for user user1 by LOGIN(uid=0) May 4 10:48:44 hoho2 login[2136]: Warning! Could not get current context for /dev/tty1, not relabeling. May 4 10:48:45 hoho2 -- user1[2136]: LOGIN ON tty1 BY user1 May 4 10:48:52 hoho2 su(pam_unix)[2175]: session opened for user root by user1(uid=500) May 4 10:48:52 hoho2 su[2175]: Warning! Could not get current context for /dev/tty1, not relabeling. May 4 10:48:52 hoho2 kernel: audit(1083685732.396:0): avc: denied { transition } for pid=2176 exe=/bin/su path=/bin/bash dev=sda2 ino=2605063 scontext=user_u:sysadm_r:sysadm_t tcontext=root:sysadm_r:sysadm_t tclass=process May 4 10:50:23 hoho2 su(pam_unix)[2175]: session closed for user root May 4 10:50:55 hoho2 su(pam_unix)[2204]: session opened for user root by user1(uid=500) May 4 10:50:55 hoho2 su[2204]: Warning! Could not get current context for /dev/tty1, not relabeling. [root at hoho2 sysconfig]# Thanks much. SELinux seems as though it might become a usable standard. The human path/process is important for newbie testers though. Too many rocks and the extra eyeballs get discouraged. From sds at epoch.ncsc.mil Tue May 4 20:13:35 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 04 May 2004 16:13:35 -0400 Subject: Humpty Dumpty In-Reply-To: References: Message-ID: <1083701614.19086.357.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2004-05-04 at 15:50, Bob Gustafson wrote: > Yesterday I downloaded some of the SELinux tool stuff and rebuilt it > from the SRPMS. (This may not have been necessary). yum install setools* > The application 'seuser' did not seem to be able to find the policy.conf > file. I found the .tcl file and hacked a bit on that, but tcl is not a > native language for me. (Today I found the /usr/share/setools/seuser.conf > file with the missing 'policy' in the policy.conf path) Known breakage, reported to the maintainers (Tresys). > Also there was something about the file_contexts - it was a file instead > of a directory at one point - so I deleted the file and redid some steps > and found a populated directory afterwards - so I must have done > something (correctly?). There is an installed file_contexts in /etc/security/selinux for runtime use, and if you have policy-sources installed, there is also the /etc/security/selinux/src/policy/file_contexts directory that contains the sources. > I went in with vim and changed the last line to read '--disabled' and > then attempted to reboot the SELinux enabled system. Wrong file. /etc/sysconfig/selinux, content should be SELINUX=disabled (or enforcing or permissive). > My immediate objective is to configure things so that I can turn > enforcing on and successfully boot my system. Maybe this is not yet > possible (not enough file_contexts set?). Try running fixfiles relabel from single user mode, then reboot. > What versions of what software are currently SElinux enabled. I have rpm > 4.3.1 - does that rpm do the right thing as far as installing the extra > file contexts? Yes. > What happens if I do an up2date. Will I load in non-SELinux programs which > will undo everything learned up to that point? yum update works correctly; I would expect up2date to do likewise, but am not certain. > What is rawhide? Is that a collection of setools? (or an ancient Fedora image?) Fedora devel tree. > How can I make the file context messages go away -correctly- (i.e., by > setting the file contexts)? Is there a mass process that will tweek all > files? fixfiles relabel, best done from single user mode. > hoho2 login: user1 > Password: > Last login: Tue May 4 10:41:38 from TZ > [user1 at hoho2 user1]$ su > Password: > audit(1083685732.396:0): avc: denied { transition } for pid=2176 > exe=/bin/su > path=/bin/bash dev=sda2 ino=2605063 scontext=user_u:sysadm_r:sysadm_t > tcontext=r > oot:sysadm_r:sysadm_t tclass=process > > I can guess that something is objectionable here, but see below when I did > it again su program wasn't labeled properly, so it didn't run in the right domain and lacked permission (but you aren't in enforcing mode). > See, here I did another su, but did not get log messages. Why? In permissive mode, SELinux only logs once per denial to avoid floods, because the application may very well keep performing the same operation endlessly since it isn't getting any denial (strictly speaking, it logs once per denial or until the cache entry is evicted, e.g. by a policy reload or just in the normal course of operation). > May 4 10:48:52 hoho2 kernel: audit(1083685732.396:0): avc: denied > { transition } for pid=2176 exe=/bin/su path=/bin/bash dev=sda2 > ino=2605063 > scontext=user_u:sysadm_r:sysadm_t tcontext=root:sysadm_r:sysadm_t > tclass=process The su process, running in the "scontext" (source security context), was denied process transition permission to the "tcontext" (target security context), so in enforcing mode, it would have been prevented from changing to the administrative role/domain. This is because su wasn't labeled properly, and the original user domain isn't authorized to directly transition (for obvious reasons). -- Stephen Smalley National Security Agency From don.patterson at tresys.com Tue May 4 20:41:00 2004 From: don.patterson at tresys.com (Don Patterson) Date: Tue, 4 May 2004 16:41:00 -0400 Subject: Humpty Dumpty In-Reply-To: Message-ID: You can configure font settings for apol in your $HOME/.apol file. -Don -----Original Message----- From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list-bounces at redhat.com] On Behalf Of Bob Gustafson Sent: Tuesday, May 04, 2004 2:50 PM To: fedora-selinux-list at redhat.com Subject: Humpty Dumpty I have newly arrived at the dangerous stage of SElinux testing - and have a few questions. Some recent history: Yesterday I downloaded some of the SELinux tool stuff and rebuilt it from the SRPMS. (This may not have been necessary). I was able to get the apol application up and running (but I think I need glasses - font size is a bit small) [- rich, thin, big enough screen] The application 'seuser' did not seem to be able to find the policy.conf file. I found the .tcl file and hacked a bit on that, but tcl is not a native language for me. (Today I found the /usr/share/setools/seuser.conf file with the missing 'policy' in the policy.conf path) Also there was something about the file_contexts - it was a file instead of a directory at one point - so I deleted the file and redid some steps and found a populated directory afterwards - so I must have done something (correctly?). [Sorry about the lack of specifics - I was just playing around - thinking that I would probably have to do it over again later - once I knew what I was doing] ------ Then I found an application 'System Settings -> Security Level' With this tool, I could turn my firewall on and also turn on something in SELinux. The SELinux button said 'Active'. I clicked on it and saw options 'Warn' and 'Disabled'. Then I went back to the Firewall settings and decided not to do anything there. Clicking the OK button at the bottom gave me a dialog box - something about 'do you want security to be on'. Since I thought security was already on, I clicked on yes... It was soon after that I attempted to 'su' -- and found out that I could not. This was (fortunately) not a production system. Even though I knew that Humpty had fallen off the wall, I figured that after a reboot - the problems would go away. Not. The reboot only progressed about half way. There were extra messages on the console screen. (This message repeated 63067847 times...) The messages stopped. I was concerned that the log files had filled up the remaining 35G of disk space. I hit the power switch. I mounted the root SCSI disk on another (non SELinux) system and saw the file: [root at hoho2 sysconfig]# pwd /etc/sysconfig [root at hoho2 sysconfig]# cat system-config-securitylevel # Configuration file for system-config-securitylevel --enabled [root at hoho2 sysconfig]# I went in with vim and changed the last line to read '--disabled' and then attempted to reboot the SELinux enabled system. No go - there was still something set that was preventing me from booting. I did not even get far enough to try to log on. ----- Fortunately, I had printed out some of the SELinux documentation (printed out, not read as yet). I noticed an email message from Hannes Mayer saying to pass 'selinux=0' to grub at boot time. This I did, and wonderfully my system booted up. It did not even have the pesky extra error messages which I had noticed for awhile when booting my running system - 'avc denied', etc. Reading a bit more of the email archive this morning, particularly the helpful message from Tom Mitchell - Mon, 3 May 2004 17:36:30 -0700 I went into grub.conf and added 'enforcing=0 selinux=1' to the kernel line and then rebooted. Success - it looks like things are back to the point where I can do more testing. My immediate objective is to configure things so that I can turn enforcing on and successfully boot my system. Maybe this is not yet possible (not enough file_contexts set?). A lesser goal would be to dynamically set and (hopefully) unset the enforcing parameter as mentioned later in Tom Mitchell's timely and very helpful email message - and then see what problems develop - in a (hopefully) controlled environment. Questions: What versions of what software are currently SElinux enabled. I have rpm 4.3.1 - does that rpm do the right thing as far as installing the extra file contexts? What happens if I do an up2date. Will I load in non-SELinux programs which will undo everything learned up to that point? [I have FC2(Test3) installed and updated to the point where there are no more updates available - and this is with a few extra 'source' paths] How do I determine whether essential programs are still SELinux enabled? What is rawhide? Is that a collection of setools? (or an ancient Fedora image?) (I would like to creep up on the concept of SecurityEnabled with lots of log messages, but not too many.. :-) ) How can I make the file context messages go away -correctly- (i.e., by setting the file contexts)? Is there a mass process that will tweek all files? Fedora Core release 1.92 (FC2 Test 3) Kernel 2.6.5-1.327custom on an i686 hoho2 login: user1 Password: Last login: Tue May 4 10:41:38 from TZ [user1 at hoho2 user1]$ su Password: audit(1083685732.396:0): avc: denied { transition } for pid=2176 exe=/bin/su path=/bin/bash dev=sda2 ino=2605063 scontext=user_u:sysadm_r:sysadm_t tcontext=r oot:sysadm_r:sysadm_t tclass=process I can guess that something is objectionable here, but see below when I did it again [root at hoho2 user1]# exit [user1 at hoho2 user1]$ date Tue May 4 10:50:49 CDT 2004 [user1 at hoho2 user1]$ su Password: [root at hoho2 user1]# See, here I did another su, but did not get log messages. Why? .. .. Could someone comment on the 'meaning' of some of these log messages (the SELinux generated ones - the other lines are left for context. [root at hoho2 sysconfig]# date Tue May 4 10:54:45 CDT 2004 [root at hoho2 sysconfig]# tail /var/log/messages May 4 10:48:33 hoho2 messagebus: messagebus startup succeeded May 4 10:48:44 hoho2 login(pam_unix)[2136]: session opened for user user1 by LOGIN(uid=0) May 4 10:48:44 hoho2 login[2136]: Warning! Could not get current context for /dev/tty1, not relabeling. May 4 10:48:45 hoho2 -- user1[2136]: LOGIN ON tty1 BY user1 May 4 10:48:52 hoho2 su(pam_unix)[2175]: session opened for user root by user1(uid=500) May 4 10:48:52 hoho2 su[2175]: Warning! Could not get current context for /dev/tty1, not relabeling. May 4 10:48:52 hoho2 kernel: audit(1083685732.396:0): avc: denied { transition } for pid=2176 exe=/bin/su path=/bin/bash dev=sda2 ino=2605063 scontext=user_u:sysadm_r:sysadm_t tcontext=root:sysadm_r:sysadm_t tclass=process May 4 10:50:23 hoho2 su(pam_unix)[2175]: session closed for user root May 4 10:50:55 hoho2 su(pam_unix)[2204]: session opened for user root by user1(uid=500) May 4 10:50:55 hoho2 su[2204]: Warning! Could not get current context for /dev/tty1, not relabeling. [root at hoho2 sysconfig]# Thanks much. SELinux seems as though it might become a usable standard. The human path/process is important for newbie testers though. Too many rocks and the extra eyeballs get discouraged. -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list From rhally at mindspring.com Tue May 4 20:58:04 2004 From: rhally at mindspring.com (Richard Hally) Date: Tue, 04 May 2004 16:58:04 -0400 Subject: Humpty Dumpty In-Reply-To: References: Message-ID: <409803DC.4040805@mindspring.com> Bob Gustafson wrote: > I have newly arrived at the dangerous stage of SElinux testing - and have a > few questions. snip > > I was able to get the apol application up and running (but I think I > need glasses - font size is a bit small) [- rich, thin, big enough screen] > There is a .apol file in your /home (or /root) that controls the font size. > The application 'seuser' did not seem to be able to find the policy.conf > file. I found the .tcl file and hacked a bit on that, but tcl is not a > native language for me. (Today I found the /usr/share/setools/seuser.conf > file with the missing 'policy' in the policy.conf path) > I believe this has been fixed in the most recent setools update. > ------ > > Then I found an application 'System Settings -> Security Level' With > this tool, I could turn my firewall on and also turn on something in > SELinux. The SELinux button said 'Active'. I clicked on it and > saw options 'Warn' and 'Disabled'. Then I went back to the Firewall > settings and decided not to do anything there. Clicking the OK button at > the bottom > gave me a dialog box - something about 'do you want security to be on'. > Since I thought security was already on, I clicked on yes... > this SELinux feature of system-config-securitylevel has been taken out for the FC2 release. IMHO, it needs some work to differentiate between setting the current state of enforcing and setting the state for the next boot of the system. The init will still use /etc/sysconfig/selinux. > Fortunately, I had printed out some of the SELinux documentation > (printed out, not read as yet). I noticed an email message from Hannes > Mayer saying to pass 'selinux=0' to grub at boot time. Careful here, kernel-2.6.5-1.349 has the selinux bootparam turned off ( I think they will reenable it) so be sure your /etc/sysconfig/selinux is set correctly when using that kernel. > > This I did, and wonderfully my system booted up. It did not even have > the pesky extra error messages which I had noticed for awhile when > booting my running system - 'avc denied', etc. > snip > > A lesser goal would be to dynamically set and (hopefully) unset the > enforcing parameter as mentioned later in Tom Mitchell's timely and very > helpful email message - and then see what problems develop - in a > (hopefully) controlled environment. > getenforce and setenforce commands allow for dynamic changes of mode. > (I would like to creep up on the concept of SecurityEnabled with lots of > log messages, but not too many.. :-) ) not quite "creep up on", Looks like you jumped right in. Welcome It looks like Stephen Smalley has answered your major questions in his reply. > The human path/process is important for newbie testers though. Too many > rocks and the extra eyeballs get discouraged. There are several HOWTOs and FAQ around but you probably already knew that. Richard Hally From aleksey at nogin.org Wed May 5 00:39:02 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Tue, 04 May 2004 17:39:02 -0700 Subject: Staff X server should be able to output to staff tty. Message-ID: <409837A6.4030105@nogin.org> allow staff_xserver_t staff_devpts_t:chr_file { read write }; audit(1083717236.610:0): avc: denied { read write } for pid=3337 exe=/usr/X11R6/bin/Xorg path=/dev/pts/5 dev= ino=7 scontext=aleksey:staff_r:staff_xserver_t tcontext=aleksey:object_r:staff_devpts_t tclass=chr_file audit(1083717236.610:0): avc: denied { read write } for pid=3337 exe=/usr/X11R6/bin/Xorg path=/dev/pts/5 dev= ino=7 scontext=aleksey:staff_r:staff_xserver_t tcontext=aleksey:object_r:staff_devpts_t tclass=chr_file policy-sources-1.11.2-21 -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From aleksey at nogin.org Wed May 5 00:40:32 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Tue, 04 May 2004 17:40:32 -0700 Subject: Kernel_t can not execute udev_exec_t? Message-ID: <40983800.10005@nogin.org> audit(1083714147.482:0): avc: denied { execute } for pid=3273 exe=/sbin/udevd name=udev dev=hda2 ino=3875498 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:udev_exec_t tclass=file audit(1083714147.552:0): avc: denied { execute } for pid=3282 exe=/sbin/udevd name=udev dev=hda2 ino=3875498 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:udev_exec_t tclass=file policy-sources-1.11.2-21 -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From bobgus at rcn.com Wed May 5 06:12:45 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Wed, 5 May 2004 01:12:45 -0500 Subject: Humpty Dumpty - some successes In-Reply-To: <1083701614.19086.357.camel@moss-spartans.epoch.ncsc.mil> References: Message-ID: Thanks much for all your replies. I did what you recommended and at the end of it all I rebooted with grub parameters 'selinux=1 enforcing=1' It does seem to be working and securely (I cannot telnet in from another system and my sound does not work ..) [I really shouldn't mention telnet on this list..] ----- I do have a few questions though - some may be OT ----- Yum must have a different header cache as the command line below refetched a lot of header files. The sources file for my up2date contains 'yum' lines - why is it not the same cache. [root at hoho2 user1]# yum install setools* ... unarj-debuginfo-0-2.63a-5 100% |=========================| 1.5 kB 00:00 pidentd-debuginfo-0-3.0.1 100% |=========================| 4.6 kB 00:00 commons-modeler-debuginfo 100% |=========================| 2.3 kB 00:00 VFlib2-debuginfo-0-2.25.6 100% |=========================| 5.6 kB 00:00 radvd-debuginfo-0-0.7.2-7 100% |=========================| 3.6 kB 00:00 Cannot find a package matching setools-1.3-2.i386.rpm Cannot find a package matching setools-gui-1.3-2.i386.rpm No actions to take [root at hoho2 user1]# I did it again with the '-t' option - got less output lines, but the Cannot find lines were still there. [root at hoho2 user1]# yum -t install setools* Gathering header information file(s) from server(s) Server: Fedora Core 1.92 - Development Tree Finding updated packages Downloading needed headers Cannot find a package matching setools-1.3-2.i386.rpm Cannot find a package matching setools-gui-1.3-2.i386.rpm No actions to take [root at hoho2 user1]# Setools is installed on my system though. (Maybe the yum default sources file is not pointed correctly?) [root at hoho2 user1]# rpm -q -i setools | more Name : setools Relocations: /usr Version : 1.3 Vendor: Red Hat, Inc. Release : 2 Build Date: Mon 19 Apr 2004 07:50:44 PM CDT Install Date: Mon 03 May 2004 01:50:24 PM CDT Build Host: tweety.devel.redhat.com [root at hoho2 user1]# rpm -q -i setools-gui | more Name : setools-gui Relocations: /usr Version : 1.3 Vendor: Red Hat, Inc. Release : 2 Build Date: Mon 19 Apr 2004 07:50:44 PM CDT Install Date: Mon 03 May 2004 01:50:38 PM CDT Build Host: tweety.devel.redhat.com Then I did: fixfiles relabel One supposes (me at least) that once 'fixfiles relabel' has been run, then a second run of that program will not find any files to fix. This was not the case for me. I actually did 'fixfiles relabel' three times and even on the last one I got diagnostic output. A typical bunch of diagnostics looked like this: Cleaning out /tmp /usr/sbin/setfiles: conflicting specifications for /lib/modules/2.6.3-2.1.253.2.1custom/modules.dep and /lib/modules/2.6.5-1.327/build/include/config/MARKER, using system_u:object_r:modules_dep_t. /usr/sbin/setfiles: conflicting specifications for /usr/src/redhat/BUILD/ooo-build-1.1.53pre/build/OOO_1_1_1/setup2/ unxlngi4.pro/bin/tplx64533.res and /var/tmp/openoffice.org-1.1.1-root/usr/lib/ooo-1.1/program/ resource/tplx64533.res, using system_u:object_r:src_t. /usr/sbin/setfiles: conflicting specifications for /usr/src/redhat/BUILD/ooo-build-1.1.53pre/build/OOO_1_1_1/ setup2/unxlngi4.pro/bin/tplx64590.res and /var/tmp/openoffice.org-1.1.1-root/usr/lib/ooo-1.1/program/resource/ tplx64590.res, using system_u:object_r:src_t. There is a pattern here, but I can't express it in fixable terms. ------ This is my new virgin login after the fixfiles and with grub parameters 'selinux=1 enforcing=0' Fedora Core release 1.92 (FC2 Test 3) Kernel 2.6.5-1.327custom on an i686 hoho2 login: user1 Password: Your default context is user_u:user_r:user_t. Do you want to choose a different one? [n] Last login: Tue May 4 11:05:30 from TZ [user1 at hoho2 user1]$ date Tue May 4 16:45:14 CDT 2004 [user1 at hoho2 user1]$ System Tools -> Sound Card Detection -> play sound May 4 19:43:51 hoho2 udev[3472]: creating device node '/udev/audio' May 4 19:43:51 hoho2 udev[3479]: creating device node '/udev/adsp' May 4 19:43:51 hoho2 kernel: audit(1083717831.232:0): avc: denied relabelfrom } for pid=3485 exe=/sbin/restorecon name=mixer dev=sda2 ino=5374112 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=lnk_file May 4 19:43:51 hoho2 kernel: audit(1083717831.232:0): avc: denied { relabelto } for pid=3485 exe=/sbin/restorecon name=mixer dev=sda2 ino=5374112 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:sound_device_t tclass=lnk_file Seems to be a problem with the sound card stuff - even though it is not enforcing at the moment. It worked before SELinux. ----- Now the acid test - reboot with grub parameters 'selinux=1 enforcing=1' Fedora Core release 1.92 (FC2 Test 3) Kernel 2.6.5-1.327custom on an i686 hoho2 login: audit(1083719173.508:0): avc: denied { getattr } for pid=2035 exe=/bin/bash path=/etc/hotplug dev=sda2 ino=1458282 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:hotplug_etc_t tclass=dir audit(1083719173.508:0): avc: denied { search } for pid=2035 exe=/bin/bash name=hotplug dev=sda2 ino=1458282 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:hotplug_etc_t tclass=dir audit(1083719173.508:0): avc: denied { search } for pid=2035 exe=/bin/bash name=hotplug dev=sda2 ino=1458282 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:hotplug_etc_t tclass=dir audit(1083719173.512:0): avc: denied { search } for pid=2035 exe=/bin/bash name=hotplug dev=sda2 ino=1458282 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:hotplug_etc_t tclass=dir audit(1083719173.513:0): avc: denied { search } for pid=2035 exe=/bin/bash name=log dev=sda2 ino=720918 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:var_log_t tclass=dir audit(1083719173.514:0): avc: denied { search } for pid=2035 exe=/bin/bash name=log dev=sda2 ino=720918 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:var_log_t tclass=dir user1 Password: Your default context is user_u:user_r:user_t. Do you want to choose a different one? [n] Last login: Tue May 4 20:27:17 from TZ [user1 at hoho2 user1]$ Lots of diagnostic messages between the login: and the 'user1' response!! --- Note that it really is enforcing --- [user1 at hoho2 user1]$ od -c /selinux/enforce 0000000 1 0000001 [user1 at hoho2 user1]$ --- However the /etc/sysconfig/selinux file still says 'disabled' [root at hoho2 user1]# cat /etc/sysconfig/selinux # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcinfg - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=disabled [root at hoho2 user1]# date Tue May 4 20:35:31 CDT 2004 [root at hoho2 user1]# (Note typo in the enforcing line of this file) Maybe the grub kernel line overrides whatever is in this file? Perhaps the information in this file controls the boot situation when there is no additional boot grub parameter? Here is a try at rsync to a machine without SELinux [root at hoho2 user1]# vim nextboot.bug [root at hoho2 user1]# rsync nextboot.bug hoho0:/home/bobg root at hoho0's password: Warning: No xauth data; using fake authentication data for X11 forwarding. Server is very old version of rsync, upgrade recommended. [root at hoho2 user1]# It seems to say that it has faked it, but no file was transfered. up2date does not work with enforcing=1 I noticed that there were a bunch more update files available, so I installed all (including the 349 kernel), and then rebooted with enforcing=1 It actually does boot - and I can also 'su' bedtime From rhally at mindspring.com Wed May 5 09:01:01 2004 From: rhally at mindspring.com (Richard Hally) Date: Wed, 05 May 2004 05:01:01 -0400 Subject: Humpty Dumpty - some successes In-Reply-To: References: Message-ID: <4098AD4D.2040507@mindspring.com> Bob Gustafson wrote: snip > > ----- I do have a few questions though - some may be OT ----- > > Yum must have a different header cache as the command line below refetched > a lot of header files. The sources file for my up2date contains 'yum' lines > - why is it not the same cache. > yes, different designs and history. yum cache is /var/cache/yum/. up2date is /var/spool/up2date/. > [root at hoho2 user1]# yum install setools* > you usually need to escape the * ...setools\* snip > > Seems to be a problem with the sound card stuff - even though it is not > enforcing at the moment. It worked before SELinux. > The sound card thing may be independent of SELinux but related to whether you did a fresh install or just did updates. > --- Note that it really is enforcing --- > > [user1 at hoho2 user1]$ od -c /selinux/enforce > 0000000 1 > 0000001 > [user1 at hoho2 user1]$ > > --- However the /etc/sysconfig/selinux file still says 'disabled' > > [root at hoho2 user1]# cat /etc/sysconfig/selinux > # This file controls the state of SELinux on the system. > # SELINUX= can take one of these three values: > # enforcinfg - SELinux security policy is enforced. > # permissive - SELinux prints warnings instead of enforcing. > # disabled - No SELinux policy is loaded. > SELINUX=disabled > [root at hoho2 user1]# date > Tue May 4 20:35:31 CDT 2004 > [root at hoho2 user1]# > > (Note typo in the enforcing line of this file) > Maybe the grub kernel line overrides whatever is in this file? Perhaps the > information in this file controls the boot situation when there is no > additional boot grub parameter? > Yes, the kernel line overrides the /etc/sysconfig/selinux. Correct on the second part also. > up2date does not work with enforcing=1 I haven't tried up2date in a while. Yum works for me in enforcing mode. > > I noticed that there were a bunch more update files available, so I > installed all (including the 349 kernel), and then rebooted with enforcing=1 with the 349 kernel check if you are actually "enforcing" with the getenforce command(or cat /selinux/enforce). Change on the fly with setenforce [0|1]. HTH Richard Hally From sds at epoch.ncsc.mil Wed May 5 12:02:41 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 05 May 2004 08:02:41 -0400 Subject: Humpty Dumpty - some successes In-Reply-To: References: Message-ID: <1083758561.8226.27.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-05-05 at 02:12, Bob Gustafson wrote: > [root at hoho2 user1]# yum install setools* Sorry, should have escaped the *, otherwise the shell may expand it for you if there are any matching files in the current working directory, and then yum won't be happy. > A typical bunch of diagnostics looked like this: > > Cleaning out /tmp > /usr/sbin/setfiles: conflicting specifications for > /lib/modules/2.6.3-2.1.253.2.1custom/modules.dep and > /lib/modules/2.6.5-1.327/build/include/config/MARKER, using > system_u:object_r:modules_dep_t. > > /usr/sbin/setfiles: conflicting specifications for > /usr/src/redhat/BUILD/ooo-build-1.1.53pre/build/OOO_1_1_1/setup2/ > unxlngi4.pro/bin/tplx64533.res and > /var/tmp/openoffice.org-1.1.1-root/usr/lib/ooo-1.1/program/ > resource/tplx64533.res, using system_u:object_r:src_t. > > /usr/sbin/setfiles: conflicting specifications for > /usr/src/redhat/BUILD/ooo-build-1.1.53pre/build/OOO_1_1_1/ > setup2/unxlngi4.pro/bin/tplx64590.res and > /var/tmp/openoffice.org-1.1.1-root/usr/lib/ooo-1.1/program/resource/ > tplx64590.res, using system_u:object_r:src_t. > > There is a pattern here, but I can't express it in fixable terms. A "conflicting specifications" warning means that setfiles thinks that the two pathnames are multiple hard links to the same inode, which can only have a single security context, but the two pathnames match entries in file_contexts that have different security contexts, so there is a conflict. setfiles will still label the inode (based on the ordering in file_contexts, with later entries taking precedence, unless there is an explicit entry for the complete pathname), but it is warning that there is an ambiguity in the specification. Repeatedly relabeling won't help, as the conflict will remain until: - the conflicting hard link is removed, or - the file_contexts configuration is altered to explicitly indicate that both pathnames should have the same context, typically by adding explicit entries for the conflicting files. > System Tools -> Sound Card Detection -> play sound > > May 4 19:43:51 hoho2 udev[3472]: creating device node '/udev/audio' > May 4 19:43:51 hoho2 udev[3479]: creating device node '/udev/adsp' > May 4 19:43:51 hoho2 kernel: audit(1083717831.232:0): avc: denied > relabelfrom } for pid=3485 exe=/sbin/restorecon name=mixer dev=sda2 > ino=5374112 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:device_t tclass=lnk_file > > May 4 19:43:51 hoho2 kernel: audit(1083717831.232:0): avc: denied { > relabelto } for pid=3485 exe=/sbin/restorecon name=mixer dev=sda2 > ino=5374112 > scontext=system_u:system_r:udev_t tcontext=system_u:object_r:sound_device_t > tclass=lnk_file > > Seems to be a problem with the sound card stuff - even though it is not > enforcing at the moment. It worked before SELinux. Not sure why udev is relabeling a symlink. Dan? Make sure that you are working with the latest policy, i.e. yum update policy. -- Stephen Smalley National Security Agency From kmacmillan at tresys.com Wed May 5 13:58:35 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Wed, 5 May 2004 09:58:35 -0400 Subject: Humpty Dumpty In-Reply-To: <409803DC.4040805@mindspring.com> Message-ID: <200405051353.i45Drj9i019219@gotham.columbia.tresys.com> > > The application 'seuser' did not seem to be able to find the policy.conf > > file. I found the .tcl file and hacked a bit on that, but tcl is not a > > native language for me. (Today I found the > /usr/share/setools/seuser.conf > > file with the missing 'policy' in the policy.conf path) > > > I believe this has been fixed in the most recent setools update. > Yes - Dan Walsh incorporated the fix into setools-1.3-2. Also, we are going to release 1.3.1 soon with this and another critical bug fixed. Karl Karl MacMillan Tresys Technology http://www.tresys.com (410)290-1411 ext 134 > > > > ------ > > > > Then I found an application 'System Settings -> Security Level' With > > this tool, I could turn my firewall on and also turn on something in > > SELinux. The SELinux button said 'Active'. I clicked on it and > > saw options 'Warn' and 'Disabled'. Then I went back to the Firewall > > settings and decided not to do anything there. Clicking the OK button at > > the bottom > > gave me a dialog box - something about 'do you want security to be on'. > > Since I thought security was already on, I clicked on yes... > > > this SELinux feature of system-config-securitylevel has been taken out > for the FC2 release. IMHO, it needs some work to differentiate between > setting the current state of enforcing and setting the state for the > next boot of the system. > The init will still use /etc/sysconfig/selinux. > > > > > Fortunately, I had printed out some of the SELinux documentation > > (printed out, not read as yet). I noticed an email message from Hannes > > Mayer saying to pass 'selinux=0' to grub at boot time. > Careful here, kernel-2.6.5-1.349 has the selinux bootparam turned off > ( I think they will reenable it) so be sure your /etc/sysconfig/selinux > is set correctly when using that kernel. > > > > This I did, and wonderfully my system booted up. It did not even have > > the pesky extra error messages which I had noticed for awhile when > > booting my running system - 'avc denied', etc. > > > > snip > > > > A lesser goal would be to dynamically set and (hopefully) unset the > > enforcing parameter as mentioned later in Tom Mitchell's timely and very > > helpful email message - and then see what problems develop - in a > > (hopefully) controlled environment. > > > getenforce and setenforce commands allow for dynamic changes of mode. > > > (I would like to creep up on the concept of SecurityEnabled with lots of > > log messages, but not too many.. :-) ) > > not quite "creep up on", Looks like you jumped right in. Welcome > > It looks like Stephen Smalley has answered your major questions in his > reply. > > > The human path/process is important for newbie testers though. Too many > > rocks and the extra eyeballs get discouraged. > There are several HOWTOs and FAQ around but you probably already knew > that. > Richard Hally > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From bobgus at rcn.com Wed May 5 15:58:49 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Wed, 5 May 2004 10:58:49 -0500 Subject: Humpty Dumpty - some successes In-Reply-To: <4098AD4D.2040507@mindspring.com> References: Message-ID: Richare Hally wrote: >Bob Gustafson wrote: snip > >> Maybe the grub kernel line overrides whatever is in this file? Perhaps the >> information in this file controls the boot situation when there is no >> additional boot grub parameter? >> > >Yes, the kernel line overrides the /etc/sysconfig/selinux. Correct on >the second part also. Booting with 'selinux=1 enforcing=1' seems to be the most straightforward at the moment - since it overrides everything else. [too bad there is a spelling difference between the boot parameter 'enforcing=1' and the disk filename '/selinux/enforce'. Also too bad about the difference between the binary nature of the boot parameter 'selinux=1' and the trinary nature of the disk file contents of '/etc/sysconfig/selinux' A possible point of confusion for newbie testers. ] ----- Actual life experience: I rebuilt the 349 kernel with a slightly different .config (with 1394 and telephony) and added the 'selinux=1 enforcing=1' to the grub line. Then boot. During the boot sequence, there are still a number of audit messages - the last involving udev with a pid of 2622. This was the last message. I thought I could hear the disk moving around - maybe more audit messages were being rejected by the caching, etc. Went down to have a coffee. When I came back, the screen was the same. Was it reasonable (??) to think that my string of successes with enforcing=1 SELinux had come to an end? There it was on the screen - a screen full of audit denied messages - and nothing further. In the process of fumbling for the power switch, I touched the keyboard (return probably). Lo & Behold - the login: prompt appeared. The system had not (yet) reached its final denied! [Perhaps this was the situation in my earlier experience where I got to the power switch first] BobG From bobgus at rcn.com Wed May 5 18:02:54 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Wed, 5 May 2004 13:02:54 -0500 Subject: Humpty Dumpty - some successes In-Reply-To: <1083758561.8226.27.camel@moss-spartans.epoch.ncsc.mil> References: Message-ID: On Wed, 05 May 2004 08:02:41 -0400 Stephen Smalley wrote: >On Wed, 2004-05-05 at 02:12, Bob Gustafson wrote: On 'fixfiles relabel' > >> A typical bunch of diagnostics looked like this: >> snip >> >> /usr/sbin/setfiles: conflicting specifications for >> /usr/src/redhat/BUILD/ooo-build-1.1.53pre/build/OOO_1_1_1/ >> setup2/unxlngi4.pro/bin/tplx64590.res and >> /var/tmp/openoffice.org-1.1.1-root/usr/lib/ooo-1.1/program/resource/ >> tplx64590.res, using system_u:object_r:src_t. >> >> There is a pattern here, but I can't express it in fixable terms. > >A "conflicting specifications" warning means that setfiles thinks that >the two pathnames are multiple hard links to the same inode, which can >only have a single security context, but the two pathnames match entries >in file_contexts that have different security contexts, so there is a >conflict. setfiles will still label the inode (based on the ordering in >file_contexts, with later entries taking precedence, unless there is an >explicit entry for the complete pathname), but it is warning that there >is an ambiguity in the specification. Repeatedly relabeling won't help, >as the conflict will remain until: >- the conflicting hard link is removed, or >- the file_contexts configuration is altered to explicitly indicate that >both pathnames should have the same context, typically by adding >explicit entries for the conflicting files. > Guessing a bit here (still need to read some of those FAQs, etc.): The idea of Security Enhancements is to come up with a way for the computer to check the safety of an operation against a list of 'safe' operations which have been created by humans. This is a daunting task because the computer is very fast and is doing new operations all the time. Necessarily, there is a performance hit (no free lunch). Skillful design hopefully will minimize the performance hit without throwing the baby away (enforcing secure policy on all operations). It is daunting from another angle too: If the list of safe operations is created by humans - there could (will) be an error somewhere in the list. Thus the tools which have been created which (hopefully) will programatically [any 'Formal Methods' here?] (prove) (check) that the list is 'correct'. This then requires some sort of 'correctness' criteria. Is this the policy files? Or are the policy files somewhere between the list of safe operations and the correctness criteria? In any case, a diagnostic-free run of 'fixfiles relabel' using a programmatically checked set of policy files should result in a pretty secure system. Yes? -- OK this is all prolog to your last sentence where the fixfiles confliction errors can be fixed by "adding explicit entries for the conflicting files". This seems a bit tedious - and never ending. Can some 'security aware' guidelines be created for other developers so that other components of Linux can be written without somebody having to write (and check) potentially erroneous entries? Kind of a Surgeon General poster. In the meantime, maybe there is a way to solve the conflicts by just whacking the unneeded files. [In my case, one of the conflicting pair seems to be redundant - with a 'tmp' in the path] Maybe this can just be an enhancement to the fixfiles algorithm snip >Make sure that you are working with the latest policy, i.e. yum update >policy. > Yes. I did yum update policy yum update yum update \* And all said that I was up to date. BobG From russell at coker.com.au Wed May 5 19:18:29 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 6 May 2004 05:18:29 +1000 Subject: Staff X server should be able to output to staff tty. In-Reply-To: <409837A6.4030105@nogin.org> References: <409837A6.4030105@nogin.org> Message-ID: <200405060518.29886.russell@coker.com.au> On Wed, 5 May 2004 10:39, Aleksey Nogin wrote: > allow staff_xserver_t staff_devpts_t:chr_file { read write }; Are you starting your xserver through a script session? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From sds at epoch.ncsc.mil Wed May 5 19:48:29 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 05 May 2004 15:48:29 -0400 Subject: Humpty Dumpty - some successes In-Reply-To: References: Message-ID: <1083786508.8226.115.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-05-05 at 14:02, Bob Gustafson wrote: > This then requires some sort of 'correctness' criteria. Is this the policy > files? Or are the policy files somewhere between the list of safe > operations and the correctness criteria? The present policy configuration is more along the lines of your "list of safe operations". It specifies allowed process-to-object and inter-process operations based on the security types of the relevant processes and objects. The security types group processes and objects into equivalence classes. Process security types are called "domains" by convention, but that is not important. The current policy language is an "assembly language" for policies. Tools such as apol from setools and slat can perform information flow analysis on these low level policies to check them against higher level security goals. The low level policies are often "discovered" for a particular application by defining an initial stub domain for the application, then exercising the application and seeing what additional permissions it needs to operate, and incrementally refining the policy. The audit2allow script converts audit messages to policy allow rules, but the resulting rules need careful review and are often not what you want. For example, you may want to introduce a new domain or type rather than allow access to an existing one. Not all denials are fatal to the operation of an application, so in some cases you simply want to silence the audit message and continue denying access (in particular, this often occurs with library functions that probe for access that is not necessarily required by the application). > In any case, a diagnostic-free run of 'fixfiles relabel' using a > programmatically checked set of policy files should result in a pretty > secure system. Yes? Hmm...well, an operating system that enforces your security goals, to the extent that implementation is correct and underlying assumptions are met ;) It certainly raises the bar in security. > Can some 'security aware' guidelines be created for other developers so > that other components of Linux can be written without somebody having to > write (and check) potentially erroneous entries? Kind of a Surgeon General > poster. > > In the meantime, maybe there is a way to solve the conflicts by just > whacking the unneeded files. [In my case, one of the conflicting pair seems > to be redundant - with a 'tmp' in the path] Maybe this can just be an > enhancement to the fixfiles algorithm Possibly greater security awareness in filesystem hierarchy standards. But the root problem is that labeling based on pathname is _bad_; the pathname doesn't tell you anything about the security properties, and a single inode can be aliased via multiple hard links or bind mounts. setfiles was only designed to perform the initial labeling of the filesystem; subsequent labeling of new files is handled by the policy rules (or in the case where the application is security-aware, the application may stipulate a particular label, but must still be authorized by the policy rules, e.g. modified cp to preserve security contexts on copied files given the -c option). -- Stephen Smalley National Security Agency From bobgus at rcn.com Wed May 5 20:42:28 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Wed, 5 May 2004 15:42:28 -0500 Subject: Humpty Dumpty - some successes In-Reply-To: <1083786508.8226.115.camel@moss-spartans.epoch.ncsc.mil> References: Message-ID: On Wed, 05 May 2004 15:48:29 -0400 Stephen Smalley wrote: > >> In any case, a diagnostic-free run of 'fixfiles relabel' using a >> programmatically checked set of policy files should result in a pretty >> secure system. Yes? > >Hmm...well, an operating system that enforces your security goals, to >the extent that implementation is correct and underlying assumptions are >met ;) It certainly raises the bar in security. > Yes indeed, SEL certainly does raise the bar in security. From bobgus at rcn.com Wed May 5 21:26:59 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Wed, 5 May 2004 16:26:59 -0500 Subject: Humpty Dumpty - some successes In-Reply-To: <1083786508.8226.115.camel@moss-spartans.epoch.ncsc.mil> References: Message-ID: >Tools such as apol from setools and slat can perform information flow ? slat ? I see that it was 'merged' around March 12th, but no real indication of where it was merged - or what name it might have after being merged. BobG From kmacmillan at tresys.com Wed May 5 21:33:14 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Wed, 5 May 2004 17:33:14 -0400 Subject: Setools 1.3.1 released Message-ID: <200405052128.i45LSO9i020808@gotham.columbia.tresys.com> Setools version 1.3.1 has been released and is available from the SELinux SourceForge cvs repository and http://www.tresys.com/selinux/index.html. This is a minor release that fixes the following bugs: - Changed default policy location for seuser. - Fixed object class filtering in transitive information flow. - Minor bug fix for sepcut and libseuser. Karl Karl MacMillan Tresys Technology http://www.tresys.com (410)290-1411 ext 134 From aleksey at nogin.org Wed May 5 22:10:06 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Wed, 05 May 2004 15:10:06 -0700 Subject: Staff X server should be able to output to staff tty. In-Reply-To: <200405060518.29886.russell@coker.com.au> References: <409837A6.4030105@nogin.org> <200405060518.29886.russell@coker.com.au> Message-ID: <4099663E.2000304@nogin.org> On 05.05.2004 12:18, Russell Coker wrote: >>allow staff_xserver_t staff_devpts_t:chr_file { read write }; > > Are you starting your xserver through a script session? > Yes, I am starting it from a script that runs "X :3 -layout $LAYOUT -auth $XAUTHORITY". -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From russell at coker.com.au Thu May 6 03:31:12 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 6 May 2004 13:31:12 +1000 Subject: Staff X server should be able to output to staff tty. In-Reply-To: <4099663E.2000304@nogin.org> References: <409837A6.4030105@nogin.org> <200405060518.29886.russell@coker.com.au> <4099663E.2000304@nogin.org> Message-ID: <200405061331.12988.russell@coker.com.au> On Thu, 6 May 2004 08:10, Aleksey Nogin wrote: > On 05.05.2004 12:18, Russell Coker wrote: > >>allow staff_xserver_t staff_devpts_t:chr_file { read write }; > > > > Are you starting your xserver through a script session? > > Yes, I am starting it from a script that runs "X :3 -layout $LAYOUT > -auth $XAUTHORITY". But are you using script(1) to do so? If not then why is it trying to access a pty? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From aleksey at nogin.org Thu May 6 04:16:22 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Wed, 05 May 2004 21:16:22 -0700 Subject: Staff X server should be able to output to staff tty. In-Reply-To: <200405061331.12988.russell@coker.com.au> References: <409837A6.4030105@nogin.org> <200405060518.29886.russell@coker.com.au> <4099663E.2000304@nogin.org> <200405061331.12988.russell@coker.com.au> Message-ID: <4099BC16.7070706@nogin.org> On 05.05.2004 20:31, Russell Coker wrote: >>>>allow staff_xserver_t staff_devpts_t:chr_file { read write }; [...] > But are you using script(1) to do so? If not then why is it trying to access > a pty? I am running it from konsole in an existing X session. (Basically, the script starts a second X server at a lower resolution and I use it when I want to drive a low-res projector and other similar circumstances). -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From leonard at den.ottolander.nl Thu May 6 11:31:18 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 06 May 2004 13:31:18 +0200 Subject: Cron daily denials Message-ID: <1083843078.4751.38.camel@athlon.localdomain> Hi, Recently installed FC2t3 on an old Pentium 166 with a screwy clock (guess I got to change the battery), so my daily cron job just ran. This system hasn't been updated to rawhide yet, but I thought I'd mention the denied messages for the cron job anyway: May 6 04:02:08 a3aan kernel: audit(1083808928.538:0): avc: denied { read } for pid=1276 exe=/bin/cat name=access_log dev=hda2 ino=390182 scontext=system_u:system_r:system_crond_t tcontext=root:object_r:httpd_log_t tclass=file May 6 04:02:13 a3aan kernel: audit(1083808933.148:0): avc: denied { read } for pid=1311 exe=/usr/bin/webalizer name=access_log dev=hda2 ino=390182 scontext=system_u:system_r:system_crond_t tcontext=root:object_r:httpd_log_t tclass=file May 6 04:02:14 a3aan kernel: audit(1083808934.725:0): avc: denied { read } for pid=1323 exe=/sbin/consoletype path=pipe:[2533] dev= ino=2533 scontext=system_u:system_r:consoletype_t tcontext=system_u:system_r:crond_t tclass=fifo_file May 6 04:02:14 a3aan kernel: audit(1083808934.725:0): avc: denied { use } for pid=1323 exe=/sbin/consoletype path=/dev/null dev=hda2 ino=66292 scontext=system_u:system_r:consoletype_t tcontext=system_u:system_r:logrotate_t tclass=fd Apache was started for the first time just 10 minutes ago, maybe that explains the denials on access_log? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From sds at epoch.ncsc.mil Thu May 6 11:41:46 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 06 May 2004 07:41:46 -0400 Subject: Humpty Dumpty - some successes In-Reply-To: References: Message-ID: <1083843706.9836.13.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-05-05 at 17:26, Bob Gustafson wrote: > >Tools such as apol from setools and slat can perform information flow > > ? slat ? > > I see that it was 'merged' around March 12th, but no real indication of > where it was merged - or what name it might have after being merged. http://www.nsa.gov/selinux/archives/slat-1.1.0.tgz. -- Stephen Smalley National Security Agency From bobgus at rcn.com Thu May 6 14:14:20 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Thu, 6 May 2004 09:14:20 -0500 Subject: Pretty unbelievable !! In-Reply-To: <1083843706.9836.13.camel@moss-spartans.epoch.ncsc.mil> References: Message-ID: I was just able to upgrade 'yum update \*' my whole system (kernel 351smp) and reboot and startx and Soundcard Detection (with sound). This was all with boot params 'selinux=1 enforcing=1' Congratulations on a pretty smooth transition. BobG From sds at epoch.ncsc.mil Thu May 6 18:05:21 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 06 May 2004 14:05:21 -0400 Subject: Pretty unbelievable !! In-Reply-To: References: Message-ID: <1083866721.10463.17.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-05-06 at 10:14, Bob Gustafson wrote: > I was just able to upgrade 'yum update \*' my whole system (kernel 351smp) > and reboot and startx and Soundcard Detection (with sound). > > This was all with boot params 'selinux=1 enforcing=1' > > Congratulations on a pretty smooth transition. Not to be paranoid, but could you run /usr/sbin/sestatus -v as root? -- Stephen Smalley National Security Agency From bobgus at rcn.com Thu May 6 19:51:37 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Thu, 6 May 2004 14:51:37 -0500 Subject: Pretty unbelievable !! In-Reply-To: <1083866721.10463.17.camel@moss-spartans.epoch.ncsc.mil> References: Message-ID: On Thu, 06 May 2004 14:05:21 -0400 Stephen Smalley wrote: >On Thu, 2004-05-06 at 10:14, Bob Gustafson wrote: >> I was just able to upgrade 'yum update \*' my whole system (kernel 351smp) >> and reboot and startx and Soundcard Detection (with sound). >> >> This was all with boot params 'selinux=1 enforcing=1' >> >> Congratulations on a pretty smooth transition. > >Not to be paranoid, but could you run /usr/sbin/sestatus -v as root? > >-- [root at hoho2 user1]# date Thu May 6 14:14:53 CDT 2004 [root at hoho2 user1]# /usr/sbin/sestatus -v SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Policy version: 17 Policy booleans: user_ping inactive Process contexts: Current context: root:sysadm_r:sysadm_t Init context: system_u:system_r:init_t /sbin/mingetty system_u:system_r:getty_t /usr/sbin/sshd system_u:system_r:sshd_t File contexts: Controlling term: root:object_r:sysadm_devpts_t /etc/passwd system_u:object_r:etc_t /etc/shadow system_u:object_r:shadow_t /bin/bash system_u:object_r:shell_exec_t /bin/login system_u:object_r:login_exec_t /bin/sh system_u:object_r:bin_t -> system_u:object_r:shell_exec_t /sbin/agetty system_u:object_r:getty_exec_t /sbin/init system_u:object_r:init_exec_t /sbin/mingetty system_u:object_r:getty_exec_t /usr/sbin/sshd system_u:object_r:sshd_exec_t /lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:shlib_t /lib/ld-linux.so.2 system_u:object_r:lib_t -> system_u:object_r:ld_so_t Do copy and paste into file from screen [root at hoho2 user1]# vim small.bug [root at hoho2 user1]# rsync small.bug hoho0:/home/bobg root at hoho0's password: Warning: No xauth data; using fake authentication data for X11 forwarding. As expected (???), but see log lines at bottom of this message. Target machine does not have rsync with selinux. Server is very old version of rsync, upgrade recommended. Uptime on the target machine (lots of things have happened in 84 days): [root at hoho0 root]# uptime 2:28pm up 84 days, 4 min, 2 users, load average: 0.00, 0.00, 0.00 [root at hoho0 root]# OK, now delicately step around the wall. [root at hoho2 user1]# setenforce 0 [root at hoho2 user1]# rsync small.bug hoho0:/home/bobg root at hoho0's password: Server is very old version of rsync, upgrade recommended. And lock the door afterwards [root at hoho2 user1]# setenforce 1 [root at hoho2 user1]# ===================== So, is it bullet-proof? What doc would help to interpret the output of sestatus? [I was reading this morning - I have about an inch of paper to go] ---- Some added info Last night, I downloaded the upgraded setools. When I installed it/them, I noticed that the policy files were recompiled as part of the 'make install'. Since the policy files had been recompiled, I figured that it would not hurt to do another 'fixfiles relabel', which was done before this morning's success with yum. BobG Also, I noticed that when I have a gnome terminal window open and do 'su', the following lines appear in /var/log/messages. Is this an unneeded artifact coming from the X window system? The fact that it was denied does not seem to affect the rootness of tasks after doing the 'su' May 6 14:37:31 hoho2 su(pam_unix)[3755]: session opened for user root by user1(uid=500) May 6 14:37:31 hoho2 kernel: audit(1083872251.894:0): avc: denied { add_name } for pid=3755 exe=/bin/su name=.xautholimVP scontext=user_u:user_r:user_su_t tcontext=root:object_r:staff_home_dir_t tclass=dir May 6 14:37:31 hoho2 kernel: audit(1083872251.894:0): avc: denied { create } for pid=3755 exe=/bin/su name=.xautholimVP scontext=user_u:user_r:user_su_t tcontext=user_u:object_r:staff_home_dir_t tclass=file May 6 14:37:31 hoho2 kernel: audit(1083872251.895:0): avc: denied { setattr } for pid=3755 exe=/bin/su name=.xautholimVP dev=sda2 ino=7290886 scontext=user_u:user_r:user_su_t tcontext=user_u:object_r:staff_home_dir_t tclass=file From twaugh at redhat.com Thu May 6 21:15:51 2004 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 6 May 2004 22:15:51 +0100 Subject: Pretty unbelievable !! In-Reply-To: References: Message-ID: <20040506211551.GJ9828@redhat.com> On Thu, May 06, 2004 at 02:51:37PM -0500, Bob Gustafson wrote: > Also, I noticed that when I have a gnome terminal window open and do 'su', > the following lines appear in /var/log/messages. > > Is this an unneeded artifact coming from the X window system? The fact that > it was denied does not seem to affect the rootness of tasks after doing the > 'su' > > May 6 14:37:31 hoho2 su(pam_unix)[3755]: session opened for user root by > user1(uid=500) > May 6 14:37:31 hoho2 kernel: audit(1083872251.894:0): avc: denied { > add_name } for pid=3755 exe=/bin/su name=.xautholimVP > scontext=user_u:user_r:user_su_t tcontext=root:object_r:staff_home_dir_t > tclass=dir This is in bugzilla. It means you can't start X applications as root and have them use your X display seemlessly. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at andrewfarris.com Fri May 7 03:56:55 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Thu, 06 May 2004 20:56:55 -0700 Subject: nVIDIA binary driver audits generated by OpenGL apps In-Reply-To: <40910118.8060900@redhat.com> References: <1083029984.18163.9.camel@CirithUngol> <408FD08B.9030000@redhat.com> <1083189918.30567.14.camel@CirithUngol> <40910118.8060900@redhat.com> Message-ID: <1083902214.11121.13.camel@CirithUngol> On Thu, 2004-04-29 at 09:20 -0400, Daniel J Walsh wrote: > diff -u base_user_macros.te~ base_user_macros.te > --- base_user_macros.te~ 2004-04-29 09:18:03.882721648 -0400 > +++ base_user_macros.te 2004-04-29 09:18:58.802372592 -0400 > @@ -250,6 +250,9 @@ > > ')dnl end ifdef xdm.te > > +# Access the special XServer devices. > +allow $1_t xserver_misc_device_t:chr_file rw_file_perms; > + > # Access the sound device. > allow $1_t sound_device_t:chr_file { getattr read write ioctl }; Ok, I must have had my policy slightly confused when I reported back that policy-1.11.2-21 had this fix... it doesn't appear to be there afterall. The other xserver_misc_devict_t changes are there, but not this one. Did this slip through the crack or are nVIDIA driver users targeted for the relaxed policy perhaps? -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lmorgul on irc.freenode.net "The only thing necessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From sds at epoch.ncsc.mil Fri May 7 14:02:55 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 07 May 2004 10:02:55 -0400 Subject: Pretty unbelievable !! In-Reply-To: References: Message-ID: <1083938575.11377.37.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-05-06 at 15:51, Bob Gustafson wrote: > [root at hoho2 user1]# /usr/sbin/sestatus -v > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: enforcing > Policy version: 17 Ok, just wanted to verify enabled and enforcing status. > Policy booleans: > user_ping inactive > > Process contexts: > Current context: root:sysadm_r:sysadm_t > Init context: system_u:system_r:init_t > /sbin/mingetty system_u:system_r:getty_t > /usr/sbin/sshd system_u:system_r:sshd_t > > File contexts: > Controlling term: root:object_r:sysadm_devpts_t > /etc/passwd system_u:object_r:etc_t > /etc/shadow system_u:object_r:shadow_t > /bin/bash system_u:object_r:shell_exec_t > /bin/login system_u:object_r:login_exec_t > /bin/sh system_u:object_r:bin_t -> > system_u:object_r:shell_exec_t > /sbin/agetty system_u:object_r:getty_exec_t > /sbin/init system_u:object_r:init_exec_t > /sbin/mingetty system_u:object_r:getty_exec_t > /usr/sbin/sshd system_u:object_r:sshd_exec_t > /lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:shlib_t > /lib/ld-linux.so.2 system_u:object_r:lib_t -> system_u:object_r:ld_so_t Looks fine. > So, is it bullet-proof? Of course not. But operating correctly. > What doc would help to interpret the output of sestatus? There is a brief man page, sestatus(8). The program was just contributed recently by Chris PeBenito of the Hardened Gentoo project. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Fri May 7 14:55:38 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 07 May 2004 10:55:38 -0400 Subject: nVIDIA binary driver audits generated by OpenGL apps In-Reply-To: <1083902214.11121.13.camel@CirithUngol> References: <1083029984.18163.9.camel@CirithUngol> <408FD08B.9030000@redhat.com> <1083189918.30567.14.camel@CirithUngol> <40910118.8060900@redhat.com> <1083902214.11121.13.camel@CirithUngol> Message-ID: <409BA36A.4030407@redhat.com> Andrew Farris wrote: >On Thu, 2004-04-29 at 09:20 -0400, Daniel J Walsh wrote: > > >>diff -u base_user_macros.te~ base_user_macros.te >>--- base_user_macros.te~ 2004-04-29 09:18:03.882721648 -0400 >>+++ base_user_macros.te 2004-04-29 09:18:58.802372592 -0400 >>@@ -250,6 +250,9 @@ >> >> ')dnl end ifdef xdm.te >> >>+# Access the special XServer devices. >>+allow $1_t xserver_misc_device_t:chr_file rw_file_perms; >>+ >> # Access the sound device. >> allow $1_t sound_device_t:chr_file { getattr read write ioctl }; >> >> > >Ok, I must have had my policy slightly confused when I reported back >that policy-1.11.2-21 had this fix... it doesn't appear to be there >afterall. The other xserver_misc_devict_t changes are there, but not >this one. > >Did this slip through the crack or are nVIDIA driver users targeted for >the relaxed policy perhaps? > > > Seems to have fallen through the cracks. I have readded it. Available in policy-1.11.3-3 From bobgus at rcn.com Fri May 7 15:18:37 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Fri, 7 May 2004 10:18:37 -0500 Subject: Slot problem In-Reply-To: <1083843706.9836.13.camel@moss-spartans.epoch.ncsc.mil> References: Message-ID: On Thu, 06 May 2004 07:41:46 -0400 Stephen Smalley wrote: >On Wed, 2004-05-05 at 17:26, Bob Gustafson wrote: >> >Tools such as apol from setools and slat can perform information flow >> >> ? slat ? >> >> I see that it was 'merged' around March 12th, but no real indication of >> where it was merged - or what name it might have after being merged. > >http://www.nsa.gov/selinux/archives/slat-1.1.0.tgz. > Thanks much, but on first usage, I have a problem: It looks like slat does not know anything about 'typealias'. Line 2792 of policy.conf is the first occurrence of 'typealias' [root at hoho2 fun]# cat do.sh slat -o slat.lts /etc/security/selinux/src/policy/policy.conf mls [root at hoho2 fun]# sh do.sh File "/etc/security/selinux/src/policy/policy.conf", line 2792, characters 1-10: syntax error policy.conf shown below: 2789 -> # net_conf_t is the type of the /etc/resolv.conf file. 2790 -> # all DHCP clients and PPP need write access to this file. 2791 -> type net_conf_t, file_type, sysadmfile; 2792 -> typealias net_conf_t alias resolv_conf_t; 2793 -> # I'm going to watch CNN now. From sds at epoch.ncsc.mil Fri May 7 16:08:41 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 07 May 2004 12:08:41 -0400 Subject: Slot problem In-Reply-To: References: Message-ID: <1083946121.11377.69.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-05-07 at 11:18, Bob Gustafson wrote: > Thanks much, but on first usage, I have a problem: > > It looks like slat does not know anything about 'typealias'. Yes, it appears that the slat parser hasn't been updated for recent changes to the policy language. I've forwarded to the slat developer/maintainer at MITRE. -- Stephen Smalley National Security Agency From kwade at redhat.com Sat May 8 00:35:33 2004 From: kwade at redhat.com (Karsten Wade) Date: 07 May 2004 17:35:33 -0700 Subject: updated SELinux FAQ Message-ID: <1083976532.26465.1465.camel@erato.phig.org> http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/ There have been some useful changes: * Table of contents for questions * Questions divided by subject * Content updated Now is a good time to give me suggestions for the Fedora Core 2 final release. File a bugzilla report with a new question (and answer, if you can) -- there is a link in the FAQ in the "Making changes/additions to the Fedora SELinux FAQ" box. Use the same link if you find any errors. Thanks - Karsten -- Karsten Wade, Tech Writer this .signature subject to random changes http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From rhally at mindspring.com Sat May 8 04:34:02 2004 From: rhally at mindspring.com (Richard Hally) Date: Sat, 08 May 2004 00:34:02 -0400 Subject: updated SELinux FAQ In-Reply-To: <1083976532.26465.1465.camel@erato.phig.org> References: <1083976532.26465.1465.camel@erato.phig.org> Message-ID: <409C633A.4090104@mindspring.com> Karsten Wade wrote: > http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/ > > There have been some useful changes: > > * Table of contents for questions > * Questions divided by subject > * Content updated > > Now is a good time to give me suggestions for the Fedora Core 2 final > release. File a bugzilla report with a new question (and answer, if you > can) -- there is a link in the FAQ in the "Making changes/additions to > the Fedora SELinux FAQ" box. > > Use the same link if you find any errors. > > Thanks - Karsten I have added this in bugzilla: Here is a question that may be worthwhile to have in the FAQ: Q: I have installed Fedora Core 2 without SELinux, what are the steps to start using SELinux? A: 1. Install the policy.rpm , policy-sources.rpm policycoreutilsrpm and (list other needed packages here.) 2. change the /etc/sysconfig/selinux file to have SELINUX=permissive (if you had selinux=0 on the kernel line in grub, take it off) 3. reboot (so that the LSM and SELinux modules will be loaded). 4. cd /etc/security/selinux/src/policy make load (to make sure the policy and file_contexts were built correctly) make relabel (this will take a while, it accesses every file on the system) 5. reboot (2nd time, to restart all programs with the correct contexts) --------- This needs to be checked. If this is not correct, please give the correct steps. HTH Richard Hally From gene at czarc.net Sat May 8 15:21:12 2004 From: gene at czarc.net (Gene Czarcinski) Date: Sat, 8 May 2004 11:21:12 -0400 Subject: policy packages Message-ID: <200405081121.12548.gene@czarc.net> I noticed that there is a new policy package in development (policy-strict-sources) to make a total of three (policy, policy-sources, and policy-strict-sources). How do the three packages relate to the old two package situation? Is policy-sources now more "relaxed" than previous versions? If it is more "relaxed", how about policy? Gene From bobgus at rcn.com Sat May 8 20:04:07 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Sat, 8 May 2004 15:04:07 -0500 Subject: updated SELinux FAQ In-Reply-To: <409C633A.4090104@mindspring.com> References: <1083976532.26465.1465.camel@erato.phig.org> <1083976532.26465.1465.camel@erato.phig.org> Message-ID: On Sat, 08 May 2004 00:34:02 -0400 Richard Hally wrote: > >Q: I have installed Fedora Core 2 without SELinux, what are the steps to > start using SELinux? >A: snip > 4. cd /etc/security/selinux/src/policy > make load > (to make sure the policy and file_contexts were built correctly) > make relabel > (this will take a while, it accesses every file on the system) (I'm coming from the newbie user side, so hopefully my questions would qualify as FAQ questions?) I added the following as a comment to your bugzilla entry. ---------- I wonder if there is a configuration problem with the policy files. In the /etc/security/selinux/src/policy/Makefile (mine at least), there is no mention of policy.17 as an output file, but I do have a policy.17 file in that directory and in the /etc/security/selinux directories (see below). Where are all of these things dropping from, and what is the source used in generating policy.15, policy.16, policy.17. Also, what is the meaning of 'load' when applied to a policy file. And how can one determine what policy file is 'active'? (whatever that means) [root at hoho2 policy]# more /home/user1/policy.bug [root at hoho2 policy]# pwd /etc/security/selinux/src/policy [root at hoho2 policy]# grep 15 Makefile $(CHECKPOLICY) -c 15 -o $(INSTALLDIR)/policy.15 policy.conf [root at hoho2 policy]# grep 16 Makefile $(CHECKPOLICY) -c 16 -o $(INSTALLDIR)/policy.16 policy.conf [root at hoho2 policy]# grep 17 Makefile [root at hoho2 policy]# ls -l ../.. total 21752 -rw-r--r-- 1 root root 86912 May 5 23:30 file_contexts -rw-r--r-- 1 root root 7369029 May 5 23:30 policy.15 -rw-r--r-- 1 root root 7370766 May 5 23:30 policy.16 -rw-r--r-- 1 root root 7371078 May 5 23:29 policy.17 drwx------ 3 root root 4096 Apr 28 21:04 src [root at hoho2 policy]# ls -l ../../policy.17 -rw-r--r-- 1 root root 7371078 May 5 23:29 ../../policy.17 [root at hoho2 policy]# ls -l policy.17 -rw------- 1 root root 7346892 Apr 28 21:04 policy.17 These are not the same files, both size and date differ. [root at hoho2 policy]# file policy.17 policy.17: SE Linux policy v17 6 symbols 7 ocons [root at hoho2 policy]# That is pretty nifty. Maybe having some sort of 'source stamp' would be a useful addition somewhere, not necessarily in the file text though. (But maybe) [root at hoho2 policy]# checkpolicy -h checkpolicy: invalid option -- h usage: checkpolicy [-b] [-d] [-c policyvers (15-17)] [-o output_file] [input_file] [root at hoho2 policy]# checkpolicy -b policy.17 checkpolicy: loading policy configuration from policy.17 security: 5 users, 7 roles, 1244 types, 1 bools security: 30 classes, 301755 rules checkpolicy: policy configuration loaded [root at hoho2 policy]# Loaded? What does that mean? Have I accidently changed my whole security configuration? No indication of what policy.conf or other files were used to make up this (binary) file. From rhally at mindspring.com Sat May 8 20:31:06 2004 From: rhally at mindspring.com (Richard Hally) Date: Sat, 08 May 2004 16:31:06 -0400 Subject: policy packages In-Reply-To: <200405081121.12548.gene@czarc.net> References: <200405081121.12548.gene@czarc.net> Message-ID: <409D438A.40508@mindspring.com> Gene Czarcinski wrote: > I noticed that there is a new policy package in development > (policy-strict-sources) to make a total of three (policy, policy-sources, and > policy-strict-sources). > > How do the three packages relate to the old two package situation? Is > policy-sources now more "relaxed" than previous versions? If it is more > "relaxed", how about policy? > > Gene > Well, when I installed policy-strict-sources, it replaced the files from the policy-sources package. Surprise! I would have thought in would have installed them under /etc/security/selinux/src/policy-strict. I hope we will be able to have both (or more) policies sources installed at the same time. If I rename src/policy to src/policy-strict can I then reinstall policy-sources? what rpm options should I use? Thanks for the help Richard Hally From rhally at mindspring.com Sat May 8 22:47:35 2004 From: rhally at mindspring.com (Richard Hally) Date: Sat, 08 May 2004 18:47:35 -0400 Subject: updated SELinux FAQ In-Reply-To: References: <1083976532.26465.1465.camel@erato.phig.org> <1083976532.26465.1465.camel@erato.phig.org> Message-ID: <409D6387.6040309@mindspring.com> Bob Gustafson wrote: > On Sat, 08 May 2004 00:34:02 -0400 Richard Hally wrote: > >>Q: I have installed Fedora Core 2 without SELinux, what are the steps to >> start using SELinux? >>A: > > > snip > > >> 4. cd /etc/security/selinux/src/policy >> make load >> (to make sure the policy and file_contexts were built correctly) >> make relabel >> (this will take a while, it accesses every file on the system) > > > (I'm coming from the newbie user side, so hopefully my questions would > qualify as FAQ questions?) > > I added the following as a comment to your bugzilla entry. > > ---------- > > I wonder if there is a configuration problem with the policy files. > > In the /etc/security/selinux/src/policy/Makefile (mine at least), there > is no mention of policy.17 as an output file, but I do have a policy.17 > file in that directory and in the /etc/security/selinux directories (see > below). > > Where are all of these things dropping from, and what is the source used > in generating policy.15, policy.16, policy.17. > > Also, what is the meaning of 'load' when applied to a policy file. And > how can one determine what policy file is 'active'? (whatever that means) > > [root at hoho2 policy]# more /home/user1/policy.bug > > [root at hoho2 policy]# pwd > /etc/security/selinux/src/policy > > [root at hoho2 policy]# grep 15 Makefile > $(CHECKPOLICY) -c 15 -o $(INSTALLDIR)/policy.15 policy.conf > [root at hoho2 policy]# grep 16 Makefile > $(CHECKPOLICY) -c 16 -o $(INSTALLDIR)/policy.16 policy.conf > [root at hoho2 policy]# grep 17 Makefile > > [root at hoho2 policy]# ls -l ../.. > total 21752 > -rw-r--r-- 1 root root 86912 May 5 23:30 file_contexts > -rw-r--r-- 1 root root 7369029 May 5 23:30 policy.15 > -rw-r--r-- 1 root root 7370766 May 5 23:30 policy.16 > -rw-r--r-- 1 root root 7371078 May 5 23:29 policy.17 > drwx------ 3 root root 4096 Apr 28 21:04 src > > > [root at hoho2 policy]# ls -l ../../policy.17 > -rw-r--r-- 1 root root 7371078 May 5 23:29 ../../policy.17 > [root at hoho2 policy]# ls -l policy.17 > -rw------- 1 root root 7346892 Apr 28 21:04 policy.17 > > These are not the same files, both size and date differ. > > [root at hoho2 policy]# file policy.17 > policy.17: SE Linux policy v17 6 symbols 7 ocons > [root at hoho2 policy]# > > That is pretty nifty. Maybe having some sort of 'source stamp' would be > a useful addition somewhere, not necessarily in the file text though. > (But maybe) > > [root at hoho2 policy]# checkpolicy -h > checkpolicy: invalid option -- h > usage: checkpolicy [-b] [-d] [-c policyvers (15-17)] [-o > output_file] [input_file] > [root at hoho2 policy]# checkpolicy -b policy.17 > checkpolicy: loading policy configuration from policy.17 > security: 5 users, 7 roles, 1244 types, 1 bools > security: 30 classes, 301755 rules > checkpolicy: policy configuration loaded > [root at hoho2 policy]# > > Loaded? What does that mean? Have I accidently changed my whole security > configuration? > > No indication of what policy.conf or other files were used to make up > this (binary) file. > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > I'm a little surprised that you didn't read the Makefile and find 'cat /selinux/policyvers'. Also the man pages help. One thing that is not really explained (that I recall) is that installing the 'policy' rpm puts pre-compiled 'policy{15,16,17}' in the "install dir" (which for this rpm is /etc/security/selinux) while installing the 'policy-sources' rpm does it's thing in /etc/security/selinux/src/policy and then builds the binary policy{15,16,17} and moves(selinux "install") them to the /etc/security/selinux/ dir. HTH Richard Hally From leonard at den.ottolander.nl Sun May 9 12:22:53 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 09 May 2004 14:22:53 +0200 Subject: Open policy bug reports Message-ID: <1084105373.4753.6.camel@athlon.localdomain> Hi Dan, I noticed there are a lot of open bug reports in bugzilla for policy issues that are already solved in the latest updates. Is there any reason why you don't close these bugs? They make it more difficult to get an impression of which issues still really need to be addressed. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From matthew.east at iue.it Mon May 10 11:32:08 2004 From: matthew.east at iue.it (Matthew East) Date: Mon, 10 May 2004 13:32:08 +0200 Subject: Cannot play audio cds Message-ID: <1084188727.2210.16.camel@localhost.localdomain> Hello, I am unable to play audio cds as user with selinux as enforcing. I use FC2T3, and gnome. When opening an audio cd with gnome cd player, it gives me the error: "Disk error" and cdp gives me: "[matt at localhost matt]$ cdp As root, please run chmod 666 /dev/cdrom to give yourself permission to access the CD-ROM device." I have tried doing "chmod 666 /dev/hdc" (this has no effect). If I set selinux to permissive, and do the command, the cd player then works. I hope that you can help me, as I am not up to scratch with how selinux works. Thanks in advance, Matt From matthew.east at iue.it Mon May 10 11:43:36 2004 From: matthew.east at iue.it (Matthew East) Date: Mon, 10 May 2004 13:43:36 +0200 Subject: Inability to shutdown or reboot from gnome Message-ID: <1084189415.2210.20.camel@localhost.localdomain> Hi, The shutdown or reboot buttons from the gnome menu do not work as user when selinux is in enforcing mode. I get the error "unknown user" and it kicks me to the gdm login screen. I'm sure this is an easy one for you guys, and I have seen the question pop up on some other lists, but have not found a satisfactory answer. Hope you can help!! thanks, Matt From leonard at den.ottolander.nl Mon May 10 14:04:04 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 10 May 2004 16:04:04 +0200 Subject: More avc denies Message-ID: <1084197844.4753.38.camel@athlon.localdomain> Hi, With the latest updates on a FC2t3 setup with SELinux running in permissive mode I am still seeing avc errors. Kernel-2.6.5-1.358, policy-1.11.3-3. Had to move in the /etc/security/selinux/policies because they were created as .rpmnews. System startup: avc: denied { read } for pid=546 exe=/sbin/lvm.static name=dri dev=hda2 ino=84499 scontext=system_u:system_r:lvm_t tcontext=system_u:object_r:dri_device_t tclass=dir avc: denied { search } for pid=546 exe=/sbin/lvm.static name=dri dev=hda2 ino=84499 scontext=system_u:system_r:lvm_t tcontext=system_u:object_r:dri_device_t tclass=dir Root console login: avc: denied { read } for pid=1559 exe=/bin/login name=.default_contexts dev=hda2 ino=437194 scontext=system_u:system_r:local_login_t tcontext=root:object_r:staff_home_dir_t tclass=file avc: denied { getattr } for pid=1559 exe=/bin/login path=/root/.default_contexts dev=hda2 ino=437194 scontext=system_u:system_r:local_login_t tcontext=root:object_r:staff_home_dir_t tclass=file ntpdate : avc: denied { getattr } for pid=1759 exe=/usr/sbin/ntpdate path=/dev/tty1 dev=hda2 ino=71082 scontext=root:system_r:ntpd_t tcontext=root:object_r:sysadm_tty_device_t tclass=chr_file avc: denied { ioctl } for pid=1759 exe=/usr/sbin/ntpdate path=/dev/tty1 dev=hda2 ino=71082 scontext=root:system_r:ntpd_t tcontext=root:object_r:sysadm_tty_device_t tclass=chr_file Daily cron (webalizer?): avc: denied { read } for pid=1818 exe=/bin/cat name=access_log dev=hda2 ino=390310 scontext=system_u:system_r:system_crond_t tcontext=root:object_r:httpd_log_t tclass=file and 20 secs later: avc: denied { execute_no_trans } for pid=1960 exe=/usr/sbin/prelink path=/lib/ld-2.3.3.so dev=hda2 ino=32386 scontext=system_u:system_r:prelink_t tcontext=system_u:object_r:ld_so_t tclass=file ssh login and su - : avc: denied { read } for pid=3489 exe=/bin/su name=.default_contexts dev=hda2 ino=437194 scontext=user_u:user_r:user_su_t tcontext=root:object_r:staff_home_dir_t tclass=file avc: denied { getattr } for pid=3489 exe=/bin/su path=/root/.default_contexts dev=hda2 ino=437194 scontext=user_u:user_r:user_su_t tcontext=root:object_r:staff_home_dir_t tclass=file avc: denied { add_name } for pid=3489 exe=/bin/su name=.xauthrQsUjb scontext=user_u:user_r:user_su_t tcontext=root:object_r:staff_home_dir_t tclass=dir avc: denied { create } for pid=3489 exe=/bin/su name=.xauthrQsUjb scontext=user_u:user_r:user_su_t tcontext=user_u:object_r:staff_home_dir_t tclass=file avc: denied { setattr } for pid=3489 exe=/bin/su name=.xauthrQsUjb dev=hda2 ino=437207 scontext=user_u:user_r:user_su_t tcontext=user_u:object_r:staff_home_dir_t tclass=file And when setenforce 1 I get tons of prelink execute_no_trans errors for prelink on /lib/ld-2.3.3.so . Maybe some of these are expected behaviour, but then a few aren't :) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From pmehta at wideopenwest.com Sat May 8 01:24:01 2004 From: pmehta at wideopenwest.com (Pratik Mehta) Date: Fri, 07 May 2004 20:24:01 -0500 Subject: SELinux in FC2-Test3 - enable Message-ID: <409C36B1.8010608@wideopenwest.com> Hi, I needed to know if this enables SELinux with FC2-Test 3 when i install: linux selinux=1 - Pratik From lkcl at lkcl.net Mon May 10 13:33:15 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 10 May 2004 13:33:15 +0000 Subject: SE Linux policy Message-ID: <20040510133314.GA12732@lkcl.net> > On Mon, 26 Apr 2004 20:05, Krzysztof Mazurczyk pl> > wrote: > > > > I have started playing with new SE Linux. I have it already > > > > running. > > > > BTW minor question: There are messages in log that > > > > /sbin/unix_verify > > > > is denied to do something. System is seemed to work well. Because > > > > /sbin/unix_verify is from libpam-modules I'm not sure what to do - > > > > ignore or add some rules to policy for /sbin/unix_verify. > > > > > > What access is denied? > > > > avc: denied { getattr } for pid=1768 exe=/sbin/unix_verify > > path=/proc/1768/mounts dev= ino=115867664 scontext=system_u:system_r: > > system_chkpwd_t tcontext=system_u:system_r:system_chkpwd_t tclass=file > > Allow this. The main policy will be changed to allow this. > russell, hi, sorry to be picking up on this from not being on this mailing list, and breaking the thread, but: yes i have the same issue - what policy files do i need to update, and with what? or, where can i obtain an updated .deb from that contains the necessary updates? i can quite happily read and interpret the policy files but do not yet have enough confidence to edit them. pointers to a document that would tell me things like: - to add a permission, go to file X and add what the scontext says to it. then go to file Y and add what the bit in brackets says. etc. etc. would be _very_ helpful. sincerely, l. From twaugh at redhat.com Mon May 10 14:31:58 2004 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 10 May 2004 15:31:58 +0100 Subject: More avc denies In-Reply-To: <1084197844.4753.38.camel@athlon.localdomain> References: <1084197844.4753.38.camel@athlon.localdomain> Message-ID: <20040510143158.GQ9828@redhat.com> On Mon, May 10, 2004 at 04:04:04PM +0200, Leonard den Ottolander wrote: > Had to move in the /etc/security/selinux/policies because they were > created as .rpmnews. You had policy-sources installed as well? I think it's expected behaviour in that case (policy-sources' %post scriptlet generates them from source). > Root console login: > avc: denied { read } for pid=1559 exe=/bin/login > name=.default_contexts dev=hda2 ino=437194 > scontext=system_u:system_r:local_login_t > tcontext=root:object_r:staff_home_dir_t tclass=file Looks like /root/.default_contexts has the wrong file context. Try after running restorecon on it. > ssh login and su - : > avc: denied { read } for pid=3489 exe=/bin/su name=.default_contexts > dev=hda2 ino=437194 scontext=user_u:user_r:user_su_t > tcontext=root:object_r:staff_home_dir_t tclass=file > avc: denied { getattr } for pid=3489 exe=/bin/su > path=/root/.default_contexts dev=hda2 ino=437194 > scontext=user_u:user_r:user_su_t tcontext=root:object_r:staff_home_dir_t > tclass=file See above. > avc: denied { add_name } for pid=3489 exe=/bin/su name=.xauthrQsUjb > scontext=user_u:user_r:user_su_t tcontext=root:object_r:staff_home_dir_t > tclass=dir > avc: denied { create } for pid=3489 exe=/bin/su name=.xauthrQsUjb > scontext=user_u:user_r:user_su_t > tcontext=user_u:object_r:staff_home_dir_t tclass=file > avc: denied { setattr } for pid=3489 exe=/bin/su name=.xauthrQsUjb > dev=hda2 ino=437207 scontext=user_u:user_r:user_su_t > tcontext=user_u:object_r:staff_home_dir_t tclass=file This is in bugzilla already: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120108 Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From leonard at den.ottolander.nl Mon May 10 16:02:04 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 10 May 2004 18:02:04 +0200 Subject: More avc denies In-Reply-To: <20040510143158.GQ9828@redhat.com> References: <1084197844.4753.38.camel@athlon.localdomain> <20040510143158.GQ9828@redhat.com> Message-ID: <1084204923.4753.42.camel@athlon.localdomain> Hi Tim, And what about the ntpdate errors? ntpdate : avc: denied { getattr } for pid=1759 exe=/usr/sbin/ntpdate path=/dev/tty1 dev=hda2 ino=71082 scontext=root:system_r:ntpd_t tcontext=root:object_r:sysadm_tty_device_t tclass=chr_file avc: denied { ioctl } for pid=1759 exe=/usr/sbin/ntpdate path=/dev/tty1 dev=hda2 ino=71082 scontext=root:system_r:ntpd_t tcontext=root:object_r:sysadm_tty_device_t tclass=chr_file And cron.daily? avc: denied { read } for pid=1818 exe=/bin/cat name=access_log dev=hda2 ino=390310 scontext=system_u:system_r:system_crond_t tcontext=root:object_r:httpd_log_t tclass=file and 20 secs later in cron: avc: denied { execute_no_trans } for pid=1960 exe=/usr/sbin/prelink path=/lib/ld-2.3.3.so dev=hda2 ino=32386 scontext=system_u:system_r:prelink_t tcontext=system_u:object_r:ld_so_t tclass=file Leonard. -- mount -t life -o ro /dev/dna /genetic/research From Jochen at herr-schmitt.de Mon May 10 16:07:56 2004 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 10 May 2004 18:07:56 +0200 Subject: Trouble booting kernel after building a kernel on a SELinux enabled system Message-ID: Hello, After I have create a kernel image on a SELinux enabled system, grub complaint a access to a invalid block when the compiled kernel should be booted. But when I turn off SELinux via a boot parameter this issue didn't occured. It will nice, if anyone give me a hint. Best Regards: Jochen Schmitt From twaugh at redhat.com Mon May 10 16:12:06 2004 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 10 May 2004 17:12:06 +0100 Subject: More avc denies In-Reply-To: <1084204923.4753.42.camel@athlon.localdomain> References: <1084197844.4753.38.camel@athlon.localdomain> <20040510143158.GQ9828@redhat.com> <1084204923.4753.42.camel@athlon.localdomain> Message-ID: <20040510161206.GA11301@redhat.com> On Mon, May 10, 2004 at 06:02:04PM +0200, Leonard den Ottolander wrote: > And what about the ntpdate errors? > And cron.daily? > and 20 secs later in cron: (I didn't reply to those, since I know nothing about them..) Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bobgus at rcn.com Mon May 10 16:36:39 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Mon, 10 May 2004 11:36:39 -0500 Subject: Inability to shutdown or reboot from gnome In-Reply-To: <1084189415.2210.20.camel@localhost.localdomain> Message-ID: Hi I get that same thing. Have you tried to do a 'setenforce 0' as root just before you do a Gnome shutdown? I tried that just now and it still halted at the console prompt (I boot into run level 3 and then do a 'startx' as user to go to Gnome after boot up) A few weeks ago, I could shutdown from the Gnome menu, but perhaps that was a bug in Gnome. A user should not be able to shutdown the system (!!). When I am at the console prompt and try to do '/sbin/shutdown -r now', I get the message now that only root can shutdown (this is proper). Whether a user can shut down from the Gnome menu seems to be not a selinux issue, but just a normal security 'tighterning up' - independent of selinux. BobG >Hi, > >The shutdown or reboot buttons from the gnome menu do not work as user >when selinux is in enforcing mode. I get the error "unknown user" and it >kicks me to the gdm login screen. I'm sure this is an easy one for you >guys, and I have seen the question pop up on some other lists, but have >not found a satisfactory answer. Hope you can help!! > >thanks, Matt From leonard at den.ottolander.nl Mon May 10 17:05:17 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 10 May 2004 19:05:17 +0200 Subject: More avc denies In-Reply-To: <20040510161206.GA11301@redhat.com> References: <1084197844.4753.38.camel@athlon.localdomain> <20040510143158.GQ9828@redhat.com> <1084204923.4753.42.camel@athlon.localdomain> <20040510161206.GA11301@redhat.com> Message-ID: <1084208717.4753.62.camel@athlon.localdomain> Hi Tim, > > And what about the ntpdate errors? > > And cron.daily? > > and 20 secs later in cron: > > (I didn't reply to those, since I know nothing about them..) That's alright. The fact that I am greeting you in my reply does not mean that I expect you personally to answer these questions (this seems to confuse more people). It was more of a status update for others who might be following the thread. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From russell at coker.com.au Mon May 10 17:42:42 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 11 May 2004 03:42:42 +1000 Subject: Cannot play audio cds In-Reply-To: <1084188727.2210.16.camel@localhost.localdomain> References: <1084188727.2210.16.camel@localhost.localdomain> Message-ID: <200405110342.42834.russell@coker.com.au> On Mon, 10 May 2004 21:32, Matthew East wrote: > I am unable to play audio cds as user with selinux as enforcing. I use > FC2T3, and gnome. When opening an audio cd with gnome cd player, it > gives me the error: "Disk error" and cdp gives me: Please give us the AVC messages related to this. The easiest way of doing so is to run "dmesg | tail" immediately after the command fails. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From dwalsh at redhat.com Mon May 10 17:46:04 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 10 May 2004 13:46:04 -0400 Subject: SELinux in FC2-Test3 - enable In-Reply-To: <409C36B1.8010608@wideopenwest.com> References: <409C36B1.8010608@wideopenwest.com> Message-ID: <409FBFDC.6050809@redhat.com> During the install add "selinux" to the install line will do it. From bobgus at rcn.com Mon May 10 18:29:45 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Mon, 10 May 2004 13:29:45 -0500 Subject: Trouble booting kernel after building a kernel on a SELinux enabled system In-Reply-To: Message-ID: Can you capture (or reproduce here) the text of grub's complaint? There may also be something in /var/log/messages or /var/log/boot.log which would be interesting. Also, assuming that you have used the boot parameters selinux=1 enforcing=0 to get your system up and running, there may be some 'audit .. denied' messages recorded or on your console during boot which might indicate what security feature is being ignored by setting 'enforcing=0' BobG >Hello, > >After I have create a kernel image on a SELinux enabled system, >grub complaint a access to a invalid block when the compiled >kernel should be booted. > >But when I turn off SELinux via a boot parameter this issue >didn't occured. > >It will nice, if anyone give me a hint. > >Best Regards: > >Jochen Schmitt > From bobgus at rcn.com Mon May 10 18:51:03 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Mon, 10 May 2004 13:51:03 -0500 Subject: Also more avc denies - up2date In-Reply-To: <1084208717.4753.62.camel@athlon.localdomain> References: <20040510161206.GA11301@redhat.com> <1084197844.4753.38.camel@athlon.localdomain> <20040510143158.GQ9828@redhat.com> <1084204923.4753.42.camel@athlon.localdomain> <20040510161206.GA11301@redhat.com> Message-ID: Also, when I try to run up2date from Gnome (started as user1) by clicking on the toolbar icon -> then clicking on 'Open up2date', then putting in root password in resulting dialog box, nothing happens after that [user1 at hoho2 user1]$ dmesg | tail -2 ... audit(1084213893.132:0): avc: denied { name_bind } for pid=3830 exe=/usr/X11R6/bin/Xorg scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:vnc_port_t tclass=tcp_socket audit(1084213926.790:0): avc: denied { transition } for pid=3991 exe=/usr/sbin/userhelper path=/usr/sbin/up2date dev=sda2 ino=3845328 scontext=user_u:user_r:user_userhelper_t tcontext=root:sysadm_r:rpm_t tclass=process [user1 at hoho2 user1]$ However, if I open a terminal window and do 'setenforce 0', and then repeat the above commands, the up2date splash opens and I can then go ahead and download updates (if there are any). It looks like the policy needs a tweek here, or maybe the problem is in Gnome? BobG From tryinlinux2004 at yahoo.com Mon May 10 16:18:04 2004 From: tryinlinux2004 at yahoo.com (Jim Higgins) Date: Mon, 10 May 2004 09:18:04 -0700 (PDT) Subject: selinux/rpm problem Message-ID: <20040510161804.48080.qmail@web50203.mail.yahoo.com> Hello, Why is it that when I install any .rpm file I get selinux line* errors, and yet it will install ok.I get a scrolling /etc/security/selinux/file_contents invalid context system_u:object_t: (and then the rpm list). Is there a script that I can edit to cure this ?? Thank You jimh __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover From Valdis.Kletnieks at vt.edu Mon May 10 19:30:31 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 10 May 2004 15:30:31 -0400 Subject: selinux/rpm problem In-Reply-To: Your message of "Mon, 10 May 2004 09:18:04 PDT." <20040510161804.48080.qmail@web50203.mail.yahoo.com> References: <20040510161804.48080.qmail@web50203.mail.yahoo.com> Message-ID: <200405101930.i4AJUVcg006995@turing-police.cc.vt.edu> On Mon, 10 May 2004 09:18:04 PDT, Jim Higgins said: > Hello, > Why is it that when I install any .rpm file I get > selinux line* errors, and yet it will install ok.I get > a scrolling /etc/security/selinux/file_contents > invalid context system_u:object_t: (and then the rpm > list). Is there a script that I can edit to cure this Only times I've hit this are when I've updated the SELinux policy, but haven't gotten it reloaded yet. cd /etc/security/selinux/src/policy; make reload should fix it. If it doesn't, let us know... (I can't remember if you need to cd /etc/security/linux instead if you have only policy but not policy-sources RPM installed....) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From leonard at den.ottolander.nl Mon May 10 20:02:01 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 10 May 2004 22:02:01 +0200 Subject: Also more avc denies - up2date In-Reply-To: References: <20040510161206.GA11301@redhat.com> <1084197844.4753.38.camel@athlon.localdomain> <20040510143158.GQ9828@redhat.com> <1084204923.4753.42.camel@athlon.localdomain> <20040510161206.GA11301@redhat.com> Message-ID: <1084219321.4747.1.camel@athlon.localdomain> Hi Bob, > Also, when I try to run up2date from Gnome (started as user1) by clicking > on the toolbar icon -> then clicking on 'Open up2date', then putting in > root password in resulting dialog box, nothing happens after that This is already in bugzilla: cannot run up2date as user_r or staff_r (http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122712). Leonard. -- mount -t life -o ro /dev/dna /genetic/research From aleksey at nogin.org Mon May 10 20:13:56 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Mon, 10 May 2004 13:13:56 -0700 Subject: Kernel_t can not execute udev_exec_t? In-Reply-To: <40983800.10005@nogin.org> References: <40983800.10005@nogin.org> Message-ID: <409FE284.8020706@nogin.org> I just filed https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122970 on this one. On 04.05.2004 17:40, Aleksey Nogin wrote: > audit(1083714147.482:0): avc: denied { execute } for pid=3273 > exe=/sbin/udevd name=udev dev=hda2 ino=3875498 > scontext=system_u:system_r:kernel_t > tcontext=system_u:object_r:udev_exec_t tclass=file > audit(1083714147.552:0): avc: denied { execute } for pid=3282 > exe=/sbin/udevd name=udev dev=hda2 ino=3875498 > scontext=system_u:system_r:kernel_t > tcontext=system_u:object_r:udev_exec_t tclass=file > > > policy-sources-1.11.2-21 -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From fedora at andrewfarris.com Mon May 10 23:12:41 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Mon, 10 May 2004 16:12:41 -0700 Subject: Cannot play audio cds In-Reply-To: <200405110342.42834.russell@coker.com.au> References: <1084188727.2210.16.camel@localhost.localdomain> <200405110342.42834.russell@coker.com.au> Message-ID: <1084230761.23659.13.camel@CirithUngol> On Tue, 2004-05-11 at 03:42 +1000, Russell Coker wrote: > On Mon, 10 May 2004 21:32, Matthew East wrote: > > I am unable to play audio cds as user with selinux as enforcing. I use > > FC2T3, and gnome. When opening an audio cd with gnome cd player, it > > gives me the error: "Disk error" and cdp gives me: > > Please give us the AVC messages related to this. The easiest way of doing so > is to run "dmesg | tail" immediately after the command fails. Probably the same issue as this open 'boog' (the avc should match the bug). https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121916 I relabel the cd devices manually as removable_device_t. Daniel Walsh said that determining which devices should be labeled removable.. and which are really fixed disks is still an unsolved problem for policy. # chcon -t removable_device_t /dev/hdc http://www.redhat.com/archives/fedora-selinux-list/2004-April/msg00333.html (no rush on this.. fc2 release consumed alot of time I am sure) :P -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lmorgul on irc.freenode.net "The only thing necessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From matthew.east at iue.it Tue May 11 08:08:05 2004 From: matthew.east at iue.it (Matthew East) Date: Tue, 11 May 2004 10:08:05 +0200 Subject: Cannot play audio cds In-Reply-To: <1084230761.23659.13.camel@CirithUngol> References: <1084188727.2210.16.camel@localhost.localdomain> <200405110342.42834.russell@coker.com.au> <1084230761.23659.13.camel@CirithUngol> Message-ID: <1084262884.2400.9.camel@localhost.localdomain> Hi, thanks for your replies, On Tue, 2004-05-11 at 01:12, Andrew Farris wrote: > On Tue, 2004-05-11 at 03:42 +1000, Russell Coker wrote: > > On Mon, 10 May 2004 21:32, Matthew East wrote: > > > I am unable to play audio cds as user with selinux as enforcing. I use > > > FC2T3, and gnome. When opening an audio cd with gnome cd player, it > > > gives me the error: "Disk error" and cdp gives me: > > > > Please give us the AVC messages related to this. The easiest way of doing so > > is to run "dmesg | tail" immediately after the command fails. > Probably the same issue as this open 'boog' (the avc should match the > bug). https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121916 Well I didn't get this AVC message, but another error message during booting (sorry I haven't conserved it) but I am convinced it is the same thing, as relabelling it as a removable_device_t has done the trick. THANKS!! > I relabel the cd devices manually as removable_device_t. Daniel Walsh > said that determining which devices should be labeled removable.. and > which are really fixed disks is still an unsolved problem for policy. > # chcon -t removable_device_t /dev/hdc From bleher at informatik.uni-muenchen.de Tue May 11 08:21:46 2004 From: bleher at informatik.uni-muenchen.de (Thomas Bleher) Date: Tue, 11 May 2004 10:21:46 +0200 Subject: Trouble booting kernel after building a kernel on a SELinux enabled system In-Reply-To: References: Message-ID: <20040511082146.GA2378@jmh.mhn.de> * Jochen Schmitt [2004-05-10 18:08]: > After I have create a kernel image on a SELinux enabled system, > grub complaint a access to a invalid block when the compiled > kernel should be booted. Any chance that the grub menu entry points to a symlink? If yes then try to replace the symlink with a real copy of the kernel image and see if the problem goes away. I have seen this problem (Debian, ext3) but haven't looked into grub yet to see what's causing this. Thomas -- http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA D09E C562 2BAE B2F4 ABE7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From tmolina at cablespeed.com Tue May 11 10:02:18 2004 From: tmolina at cablespeed.com (Thomas Molina) Date: Tue, 11 May 2004 06:02:18 -0400 (EDT) Subject: More avc denies In-Reply-To: <20040510143158.GQ9828@redhat.com> References: <1084197844.4753.38.camel@athlon.localdomain> <20040510143158.GQ9828@redhat.com> Message-ID: On Mon, 10 May 2004, Tim Waugh wrote: > On Mon, May 10, 2004 at 04:04:04PM +0200, Leonard den Ottolander wrote: > > > Had to move in the /etc/security/selinux/policies because they were > > created as .rpmnews. > > You had policy-sources installed as well? I think it's expected > behaviour in that case (policy-sources' %post scriptlet generates them > from source). I must be having a senior moment because I looked in the above directory and managed to confuse myself. If the rpmnew files are the newer files, why do they have the older date/time? Here is my ls: [root at dad selinux]# ls -la total 43600 drwxr-xr-x 3 root root 4096 May 8 19:35 . drwxr-xr-x 4 root root 4096 May 8 19:35 .. -rw-r--r-- 1 root root 86792 May 8 19:35 file_contexts -rw-r--r-- 1 root root 88017 Apr 28 22:04 file_contexts.rpmnew -rw-r--r-- 1 root root 7383775 May 8 19:35 policy.15 -rw-r--r-- 1 root root 7383775 May 7 11:24 policy.15.rpmnew -rw-r--r-- 1 root root 7385512 May 8 19:35 policy.16 -rw-r--r-- 1 root root 7385512 May 7 11:24 policy.16.rpmnew -rw-r--r-- 1 root root 7385824 May 8 19:35 policy.17 -rw-r--r-- 1 root root 7385824 May 7 11:24 policy.17.rpmnew drwx------ 3 root root 4096 May 7 11:24 src From Jochen at herr-schmitt.de Tue May 11 17:46:47 2004 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 11 May 2004 19:46:47 +0200 Subject: Trouble booting kernel after building a kernel on a SELinux enabled system In-Reply-To: References: Message-ID: On Mon, 10 May 2004 13:29:45 -0500, you wrote: >There may also be something in /var/log/messages or /var/log/boot.log which >would be interesting. How can be anything in /var/log/message or /var/log/boot.log, when grub was not able to load the kernel image? >to get your system up and running, there may be some 'audit .. denied' >messages recorded or on your console during boot which might indicate what >security feature is being ignored by setting 'enforcing=0' Sorry, I don't get any access denied message, becouse the kernel could not be loaded. Best Regards: Jochen Schmitt From rhally at mindspring.com Tue May 11 18:38:41 2004 From: rhally at mindspring.com (Richard Hally) Date: Tue, 11 May 2004 14:38:41 -0400 Subject: More avc denies In-Reply-To: References: <1084197844.4753.38.camel@athlon.localdomain> <20040510143158.GQ9828@redhat.com> Message-ID: <40A11DB1.1030507@mindspring.com> Thomas Molina wrote: > > On Mon, 10 May 2004, Tim Waugh wrote: > > >>On Mon, May 10, 2004 at 04:04:04PM +0200, Leonard den Ottolander wrote: >> >> >>>Had to move in the /etc/security/selinux/policies because they were >>>created as .rpmnews. >> >>You had policy-sources installed as well? I think it's expected >>behaviour in that case (policy-sources' %post scriptlet generates them >>from source). > > > I must be having a senior moment because I looked in the above directory > and managed to confuse myself. If the rpmnew files are the newer files, > why do they have the older date/time? Here is my ls: > > [root at dad selinux]# ls -la > total 43600 > drwxr-xr-x 3 root root 4096 May 8 19:35 . > drwxr-xr-x 4 root root 4096 May 8 19:35 .. > -rw-r--r-- 1 root root 86792 May 8 19:35 file_contexts > -rw-r--r-- 1 root root 88017 Apr 28 22:04 file_contexts.rpmnew > -rw-r--r-- 1 root root 7383775 May 8 19:35 policy.15 > -rw-r--r-- 1 root root 7383775 May 7 11:24 policy.15.rpmnew > -rw-r--r-- 1 root root 7385512 May 8 19:35 policy.16 > -rw-r--r-- 1 root root 7385512 May 7 11:24 policy.16.rpmnew > -rw-r--r-- 1 root root 7385824 May 8 19:35 policy.17 > -rw-r--r-- 1 root root 7385824 May 7 11:24 policy.17.rpmnew > drwx------ 3 root root 4096 May 7 11:24 src > When the policy rpm is installed(or updated) it puts the .rpmnew files in place. (the date is from when they were built on the build system). Then the policy-source package is installed and the files (policy.n and file_contexts) are built as part of the install(or update). I always delete the .rpmnew file. HTH Richard Hally From bobgus at rcn.com Tue May 11 20:04:54 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Tue, 11 May 2004 15:04:54 -0500 Subject: More avc denies In-Reply-To: <40A11DB1.1030507@mindspring.com> References: <1084197844.4753.38.camel@athlon.localdomain> <20040510143158.GQ9828@redhat.com> Message-ID: On Tue, 11 May 2004 14:38:41 -0400 Richard Hally wrote: > > I always delete the .rpmnew file. > >HTH Well, that's good to know. I think I just renamed the .rpmnew file over the plain.. BobG From bobgus at rcn.com Tue May 11 20:11:05 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Tue, 11 May 2004 15:11:05 -0500 Subject: Trouble booting kernel after building a kernel on a SELinux enabled system In-Reply-To: References: Message-ID: On Tue, 11 May 2004 19:46:47 +0200 Jochen Schmitt wrote: >On Mon, 10 May 2004 13:29:45 -0500, you wrote: snip > >Sorry, I don't get any access denied message, becouse the kernel >could not be loaded. > Boot your kernel with the grub boot line parameter 'selinux=0' (no quotes). You have the opportunity to put this parameter in by pressing the 'a' key when the Grub splash screen comes up. Enter on the line starting with 'kernel..' This parameter removes the selinux stuff from the kernel (more or less - as I understand it). If your kernel does not boot, then the problem is probably somewhere else other than selinux. Good Luck BobG From bobgus at rcn.com Tue May 11 20:19:15 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Tue, 11 May 2004 15:19:15 -0500 Subject: Inability to shutdown or reboot from gnome In-Reply-To: <1084262647.2400.4.camel@localhost.localdomain> References: Message-ID: I did some more experiments last night and found that if you boot with the Grub parameter 'selinux=0' and then login as a user and then go to Gnome by typing 'startx', you are then able to shutdown the system from the Gnome buttons - even though you are only a user. Keep in mind that under these conditions, you don't get any of the advantages of selinux. This is probably not what you want to happen in the long run. BobG On Tue, 11 May 2004 10:04:07 +0200 Matthew East wrote:>Hi Bob, thanks for your mail. Am replying just to you because I guess >that I might annoy the list, as you say, it is not an selinux issue. > >Sorry about that! > >I thought I had tried to set selinux to permissive before shutting down >from gnome, and it had worked, but I've tried it just now and it's the >same story. So I guess I'll just try and remove the buttons from gnome, >at least that way it will be tidier. I saw some threads on the >fedora-list about that so I'll go and read up. ;) > >thanks again. > >Matt > >On Mon, 2004-05-10 at 18:36, Bob Gustafson wrote: >> Hi >> >> I get that same thing. >> >> Have you tried to do a 'setenforce 0' as root just before you do a Gnome >> shutdown? >> >> I tried that just now and it still halted at the console prompt (I boot >> into run level 3 and then do a 'startx' as user to go to Gnome after boot >> up) >> >> A few weeks ago, I could shutdown from the Gnome menu, but perhaps that was >> a bug in Gnome. A user should not be able to shutdown the system (!!). >> >> When I am at the console prompt and try to do '/sbin/shutdown -r now', I >> get the message now that only root can shutdown (this is proper). >> >> Whether a user can shut down from the Gnome menu seems to be not a selinux >> issue, but just a normal security 'tighterning up' - independent of selinux. >> >> BobG >> >> >> >> >Hi, >> > >> >The shutdown or reboot buttons from the gnome menu do not work as user >> >when selinux is in enforcing mode. I get the error "unknown user" and it >> >kicks me to the gdm login screen. I'm sure this is an easy one for you >> >guys, and I have seen the question pop up on some other lists, but have >> >not found a satisfactory answer. Hope you can help!! >> > >> >thanks, Matt From shahms at shahms.com Tue May 11 21:49:23 2004 From: shahms at shahms.com (Shahms King) Date: Tue, 11 May 2004 14:49:23 -0700 Subject: Inability to shutdown or reboot from gnome In-Reply-To: References: Message-ID: <1084312163.3400.267.camel@shahms.mesd.k12.or.us> This bug isn't related to SELinux (it appears with SELinux enabled, disabled and permissive). Additionally, the ability to shut down the computer as a regular user is only available to local logins, meaning it is an almost non-existent security problem. If a user has physical access to the computer, they have complete control of the computer. Allowing them to shutdown and reboot becomes a data integrity issue at that point (if a user, present at the console, cannot restart the computer in the "proper" way, they can *always* power cycle it.) All of that being said, the "unknown user" bug is really irritating ... -- Shahms King From tmolina at cablespeed.com Tue May 11 23:43:11 2004 From: tmolina at cablespeed.com (Thomas Molina) Date: Tue, 11 May 2004 19:43:11 -0400 (EDT) Subject: More avc denies In-Reply-To: <40A11DB1.1030507@mindspring.com> References: <1084197844.4753.38.camel@athlon.localdomain> <20040510143158.GQ9828@redhat.com> <40A11DB1.1030507@mindspring.com> Message-ID: > When the policy rpm is installed(or updated) it puts the .rpmnew files > in place. (the date is from when they were built on the build system). > Then the policy-source package is installed and the files (policy.n and > file_contexts) are built as part of the install(or update). > > I always delete the .rpmnew file. OK, so now I am confused again. I moved all the rpmnew files to /tmp and did an rpm -V policy. I got the following: [root at dad root]# rpm -V policy .......TC c /etc/security/default_contexts .......TC c /etc/security/default_type .......TC c /etc/security/failsafe_context .......TC c /etc/security/initrc_context S.5....TC c /etc/security/selinux/file_contexts ..5....T. c /etc/security/selinux/policy.15 ..5....T. c /etc/security/selinux/policy.16 ..5....T. c /etc/security/selinux/policy.17 .......TC c /root/.default_contexts Then I moved the "regular" files to /tmp and moved the rpmnew files into their places and got the following: [root at dad root]# rpm -V policy .......TC c /etc/security/default_contexts .......TC c /etc/security/default_type .......TC c /etc/security/failsafe_context .......TC c /etc/security/initrc_context .......T. c /etc/security/selinux/file_contexts .......TC c /root/.default_contexts Which seems to indicate that the rpmnew files should be copied over the "old" files. As I recall, there are rpmorig and rpmnew files that get installed with an rpm. rpmorig files are put into place when the new config file replaces the old one and the old one is saved as the rpmorig. The rpmnew file should then be where the old file is kept in place, but the new file is saved "on the side". Is there "official" word? This is really dumb that this bugs me this much. From leonard at den.ottolander.nl Wed May 12 00:20:02 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 12 May 2004 02:20:02 +0200 Subject: More avc denies In-Reply-To: References: <1084197844.4753.38.camel@athlon.localdomain> <20040510143158.GQ9828@redhat.com> <40A11DB1.1030507@mindspring.com> Message-ID: <1084321202.4754.17.camel@athlon.localdomain> Hello Thomas, > OK, so now I am confused again. I moved all the rpmnew files to /tmp and > did an rpm -V policy. I got the following: The problem is that policy and policy-sources somewhat conflict. In case both are installed the policy files will be added as .rpmnew, and the policies are recreated from policy-sources. These recreated policies should be identical in function with those from policy, but don't necessarily have the same checksum. (Not sure what happens on an update of policy-sources when you edited them, I guess policy-sources will then be installed as .rpmnew as well). Leonard. -- mount -t life -o ro /dev/dna /genetic/research From tmolina at cablespeed.com Wed May 12 09:58:08 2004 From: tmolina at cablespeed.com (Thomas Molina) Date: Wed, 12 May 2004 05:58:08 -0400 (EDT) Subject: policy and policy-source confusion In-Reply-To: <1084321202.4754.17.camel@athlon.localdomain> References: <1084197844.4753.38.camel@athlon.localdomain> <20040510143158.GQ9828@redhat.com> <40A11DB1.1030507@mindspring.com> <1084321202.4754.17.camel@athlon.localdomain> Message-ID: On Wed, 12 May 2004, Leonard den Ottolander wrote: > Hello Thomas, > > > OK, so now I am confused again. I moved all the rpmnew files to /tmp and > > did an rpm -V policy. I got the following: > > The problem is that policy and policy-sources somewhat conflict. In case > both are installed the policy files will be added as .rpmnew, and the > policies are recreated from policy-sources. These recreated policies > should be identical in function with those from policy, but don't > necessarily have the same checksum. (Not sure what happens on an update > of policy-sources when you edited them, I guess policy-sources will then > be installed as .rpmnew as well). "somewhat conflict"? What is that supposed to mean? From my point of view, the current situation violates standard practice and the intent of the rpm system. Actual practice doesn't match the docs either. The FAQ says: "Installing or updating the policy package loads the new policy after it installs the files. Similarly, installing or updating the policy-sources package rebuilds the policy. file as well as the file_contexts file, then loads them as the currently effective policy." So if I have both policy and policy-sources, and update both the policy.version file gets rebuilt/installed twice? That can't be right. If the rpmnew files should just be deleted, they shouldn't even be created in the first place. In this case the policy package validates with the wrong set of files in place. In my opinion installing/updating one package shouldn't modify files belonging to another package. If policy-source is going to do this it should be a specific action by the user post-installation, not a part of the installation process itself. From dwalsh at redhat.com Wed May 12 12:12:05 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 12 May 2004 08:12:05 -0400 Subject: Open policy bug reports In-Reply-To: <1084105373.4753.6.camel@athlon.localdomain> References: <1084105373.4753.6.camel@athlon.localdomain> Message-ID: <40A21495.8060701@redhat.com> Leonard den Ottolander wrote: >Hi Dan, > >I noticed there are a lot of open bug reports in bugzilla for policy >issues that are already solved in the latest updates. > >Is there any reason why you don't close these bugs? They make it more >difficult to get an impression of which issues still really need to be >addressed. > >Leonard. > > > After I fix a bug I mark it as modified and wait for the reporter, QA or some other kind soul to verify that the fix works. Usually after about a month, I go in bulk close all modified bugs that no one responded too. Dan From dwalsh at redhat.com Wed May 12 12:16:58 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 12 May 2004 08:16:58 -0400 Subject: policy packages In-Reply-To: <409D438A.40508@mindspring.com> References: <200405081121.12548.gene@czarc.net> <409D438A.40508@mindspring.com> Message-ID: <40A215BA.6010704@redhat.com> Richard Hally wrote: > Gene Czarcinski wrote: > >> I noticed that there is a new policy package in development >> (policy-strict-sources) to make a total of three (policy, >> policy-sources, and policy-strict-sources). >> >> How do the three packages relate to the old two package situation? >> Is policy-sources now more "relaxed" than previous versions? If it >> is more "relaxed", how about policy? >> >> Gene >> > > Well, when I installed policy-strict-sources, it replaced the files > from the policy-sources package. Surprise! I would have thought in > would have installed them under > /etc/security/selinux/src/policy-strict. I hope we will be able to > have both (or more) policies sources installed at the same time. > If I rename src/policy to src/policy-strict can I then reinstall > policy-sources? what rpm options should I use? > Thanks for the help > Richard Hally Yes that was a mistake that it got out. I am working on a new version of the policy src rpm. It will create 4 rpms. policy and policy-sources which will contain the targeted policy (relaxed) policy. policy-strict and policy-strict-sources which will contain the strict policy (The policy we currently ship). This should be available in the first rawhide versions of FC3. Policy sources will install in /etc/security/selinux/targeted/src/policy. Strict policy sources will install in /etc/security/selinux/strict/src/policy. Dan > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From Jochen at herr-schmitt.de Wed May 12 14:44:55 2004 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 12 May 2004 16:44:55 +0200 Subject: Trouble booting kernel after building a kernel on a SELinux enabled system In-Reply-To: <20040511082146.GA2378@jmh.mhn.de> References: <20040511082146.GA2378@jmh.mhn.de> Message-ID: On Tue, 11 May 2004 10:21:46 +0200, you wrote: >Any chance that the grub menu entry points to a symlink? If yes then try >to replace the symlink with a real copy of the kernel image and see if >the problem goes away. >I have seen this problem (Debian, ext3) but haven't looked into grub yet >to see what's causing this. I think, it was a grub related issue. After I have updated grub to the lastest rawhide release, i could not reproduce the issue. Best Regards: Jochen Schmitt From kmacmillan at tresys.com Wed May 12 14:50:37 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Wed, 12 May 2004 10:50:37 -0400 Subject: policy packages In-Reply-To: <40A215BA.6010704@redhat.com> Message-ID: <200405121450.i4CEoZSf011818@gotham.columbia.tresys.com> > -----Original Message----- > > > > Well, when I installed policy-strict-sources, it replaced the files > > from the policy-sources package. Surprise! I would have thought in > > would have installed them under > > /etc/security/selinux/src/policy-strict. I hope we will be able to > > have both (or more) policies sources installed at the same time. > > If I rename src/policy to src/policy-strict can I then reinstall > > policy-sources? what rpm options should I use? > > Thanks for the help > > Richard Hally > > > Yes that was a mistake that it got out. I am working on a new version > of the policy src rpm. It will create 4 rpms. policy and > policy-sources which will contain the targeted policy (relaxed) policy. > policy-strict and policy-strict-sources which will contain the strict > policy (The policy we currently ship). This should be available in the > first rawhide versions of FC3. Policy sources will install in > /etc/security/selinux/targeted/src/policy. Strict policy sources will > install in /etc/security/selinux/strict/src/policy. > Will there be any way to determine which policy is currently active? Also, I am concerned that the well known location for the policy source (/etc/security/selinux/src/policy/) will go away and break tools that expect it. All of our tools are configurable, of course, but this change will make it hard to provide good configuration defaults. What about making /etc/security/selinux/src/policy a symlink to the currently active policy? Karl Karl MacMillan Tresys Technology http://www.tresys.com (410)290-1411 ext 134 > Dan > > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Wed May 12 15:13:47 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 12 May 2004 11:13:47 -0400 Subject: policy packages In-Reply-To: <200405121450.i4CEoZSf011818@gotham.columbia.tresys.com> References: <200405121450.i4CEoZSf011818@gotham.columbia.tresys.com> Message-ID: <40A23F2B.9060909@redhat.com> Karl MacMillan wrote: >>-----Original Message----- >> >> >>>Well, when I installed policy-strict-sources, it replaced the files >>>from the policy-sources package. Surprise! I would have thought in >>>would have installed them under >>>/etc/security/selinux/src/policy-strict. I hope we will be able to >>>have both (or more) policies sources installed at the same time. >>>If I rename src/policy to src/policy-strict can I then reinstall >>>policy-sources? what rpm options should I use? >>>Thanks for the help >>>Richard Hally >>> >>> >>Yes that was a mistake that it got out. I am working on a new version >>of the policy src rpm. It will create 4 rpms. policy and >>policy-sources which will contain the targeted policy (relaxed) policy. >>policy-strict and policy-strict-sources which will contain the strict >>policy (The policy we currently ship). This should be available in the >>first rawhide versions of FC3. Policy sources will install in >>/etc/security/selinux/targeted/src/policy. Strict policy sources will >>install in /etc/security/selinux/strict/src/policy. >> >> >> > >Will there be any way to determine which policy is currently active? Also, I >am concerned that the well known location for the policy source >(/etc/security/selinux/src/policy/) will go away and break tools that expect >it. All of our tools are configurable, of course, but this change will make >it hard to provide good configuration defaults. What about making >/etc/security/selinux/src/policy a symlink to the currently active policy? > >Karl > >Karl MacMillan >Tresys Technology >http://www.tresys.com >(410)290-1411 ext 134 > > > >>Dan >> >> >> >>>-- >>>fedora-selinux-list mailing list >>>fedora-selinux-list at redhat.com >>>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> >>> >>-- >>fedora-selinux-list mailing list >>fedora-selinux-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > We could change a sym link. We were thinking of using /etc/sysconfig/selinux to specify which policy is in use, and where the directories are. Right now I am just trying to get the SRPM to build both policy groups. The only tools that should be affected are those that deal with the src dir, which is the SEtools. From leonard at den.ottolander.nl Wed May 12 16:13:27 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 12 May 2004 18:13:27 +0200 Subject: Open policy bug reports In-Reply-To: <40A21495.8060701@redhat.com> References: <1084105373.4753.6.camel@athlon.localdomain> <40A21495.8060701@redhat.com> Message-ID: <1084378406.4746.60.camel@athlon.localdomain> Hi Dan, > After I fix a bug I mark it as modified and wait for the reporter, QA or > some other kind soul to verify that the fix works. Usually after about > a month, I go in bulk close all modified bugs that no one responded > too. I beat you to it ;-) . As I didn't get an answer for a couple of days I thought I'd close out a few bugs myself. But your strategy looks good so I'll leave you to your own work :) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed May 12 16:34:43 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 12 May 2004 18:34:43 +0200 Subject: policy and policy-source confusion In-Reply-To: References: <1084197844.4753.38.camel@athlon.localdomain> <20040510143158.GQ9828@redhat.com> <40A11DB1.1030507@mindspring.com> <1084321202.4754.17.camel@athlon.localdomain> Message-ID: <1084379683.4746.73.camel@athlon.localdomain> Hello Thomas, > If the rpmnew files should just be deleted, they shouldn't even be created > in the first place. In this case the policy package validates with the > wrong set of files in place. This is not entirely true. If you for example upgrade apache httpd.conf will also be installed as httpd.conf.rpmnew, to save your modified config file. > In my opinion installing/updating one package shouldn't modify files > belonging to another package. If policy-source is going to do this it > should be a specific action by the user post-installation, not a part of > the installation process itself. I thought I saw this in bugzilla, but can't find it. Maybe on IRC? Thread on fedora-test/-devel? Dunno. Anyway, there are others who think policy and policy-sources should mutually exclude each other. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From Jochen at herr-schmitt.de Wed May 12 17:02:59 2004 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 12 May 2004 19:02:59 +0200 Subject: Difference between policy-sources and policy-strict-sources Message-ID: <20040512170259.GA2923@myhome> Hello, I have found the packages policy-sources-1.11.3-3 and policy-strict-sources-1.11.3-3 in the rawhide repository. I was wondering, that both packages can installed on the same system. when I enter $ rpm -qi I could found out, that both packages are based on the same Source RPM. After I have got the filelist of both packages with $ rpm -ql I have found out, that both packages contains the same files. It will be nice, if anyone can explain be the aint to build both packages and why it is possible to installed both on the same machine. I think, policy-strict-sources should contains policies with more restrictive rigths, so I assume, there should be a conflict between both packages. Best Regards: Jochen Schmitt From gene at czarc.net Wed May 12 13:07:23 2004 From: gene at czarc.net (Gene Czarcinski) Date: Wed, 12 May 2004 09:07:23 -0400 Subject: policy packages In-Reply-To: <40A215BA.6010704@redhat.com> References: <200405081121.12548.gene@czarc.net> <409D438A.40508@mindspring.com> <40A215BA.6010704@redhat.com> Message-ID: <200405120907.23173.gene@czarc.net> On Wednesday 12 May 2004 08:16, Daniel J Walsh wrote: > Yes that was a mistake that it got out. I am working on a new version > of the policy src rpm. It will create 4 rpms. policy and > policy-sources which will contain the targeted policy (relaxed) policy. > policy-strict and policy-strict-sources which will contain the strict > policy (The policy we currently ship). This should be available in the > first rawhide versions of FC3. Policy sources will install in > /etc/security/selinux/targeted/src/policy. Strict policy sources will > install in /etc/security/selinux/strict/src/policy. OK, sounds good. Since it appears that you can install all four packages from your description, will you be able to select between "relaxed" (I prefer calling it perhaps "limited") and the "strict" policy via /etc/sysconfig/selinux? Gene From rhally at mindspring.com Wed May 12 19:08:42 2004 From: rhally at mindspring.com (Richard Hally) Date: Wed, 12 May 2004 15:08:42 -0400 Subject: Difference between policy-sources and policy-strict-sources In-Reply-To: <20040512170259.GA2923@myhome> References: <20040512170259.GA2923@myhome> Message-ID: <40A2763A.9080600@mindspring.com> Jochen Schmitt wrote: > Hello, > > I have found the packages policy-sources-1.11.3-3 and > policy-strict-sources-1.11.3-3 in the rawhide repository. > > I was wondering, that both packages can installed on the same system. > > when I enter > > $ rpm -qi > > I could found out, that both packages are based on the same Source RPM. > > After I have got the filelist of both packages with > > $ rpm -ql > > I have found out, that both packages contains the same files. > > It will be nice, if anyone can explain be the aint to build both packages and > why it is possible to installed both on the same machine. > > I think, policy-strict-sources should contains policies with more restrictive > rigths, so I assume, there should be a conflict between both packages. > > Best Regards: Jochen Schmitt > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > Here is Dan Walsh's answer from another thread in case you didn't see it. " Yes that was a mistake that it got out. I am working on a new version of the policy src rpm. It will create 4 rpms. policy and policy-sources which will contain the targeted policy (relaxed) policy. policy-strict and policy-strict-sources which will contain the strict policy (The policy we currently ship). This should be available in the first rawhide versions of FC3. Policy sources will install in /etc/security/selinux/targeted/src/policy. Strict policy sources will install in /etc/security/selinux/strict/src/policy. Dan " HTH Richard Hally From rhally at mindspring.com Wed May 12 19:35:01 2004 From: rhally at mindspring.com (Richard Hally) Date: Wed, 12 May 2004 15:35:01 -0400 Subject: policy packages In-Reply-To: <40A23F2B.9060909@redhat.com> References: <200405121450.i4CEoZSf011818@gotham.columbia.tresys.com> <40A23F2B.9060909@redhat.com> Message-ID: <40A27C65.2030209@mindspring.com> Daniel J Walsh wrote: > Karl MacMillan wrote: > >>> -----Original Message----- >>> >>> >>>> Well, when I installed policy-strict-sources, it replaced the files >>>> from the policy-sources package. Surprise! I would have thought in >>>> would have installed them under >>>> /etc/security/selinux/src/policy-strict. I hope we will be able to >>>> have both (or more) policies sources installed at the same time. >>>> If I rename src/policy to src/policy-strict can I then reinstall >>>> policy-sources? what rpm options should I use? >>>> Thanks for the help >>>> Richard Hally >>>> >>> >>> Yes that was a mistake that it got out. I am working on a new version >>> of the policy src rpm. It will create 4 rpms. policy and >>> policy-sources which will contain the targeted policy (relaxed) policy. >>> policy-strict and policy-strict-sources which will contain the strict >>> policy (The policy we currently ship). This should be available in the >>> first rawhide versions of FC3. Policy sources will install in >>> /etc/security/selinux/targeted/src/policy. Strict policy sources will >>> install in /etc/security/selinux/strict/src/policy. >>> >>> >> >> >> Will there be any way to determine which policy is currently active? >> Also, I >> am concerned that the well known location for the policy source >> (/etc/security/selinux/src/policy/) will go away and break tools that >> expect >> it. All of our tools are configurable, of course, but this change will >> make >> it hard to provide good configuration defaults. What about making >> /etc/security/selinux/src/policy a symlink to the currently active >> policy? >> >> Karl >> >> Karl MacMillan >> Tresys Technology >> http://www.tresys.com >> (410)290-1411 ext 134 >> >> >> >> >> > We could change a sym link. We were thinking of using > /etc/sysconfig/selinux to specify which policy is in use, and where the > directories are. Right now I am just trying to get the SRPM to build > both policy groups. The only tools that should be affected are those > that deal with the src dir, which is the SEtools. > -- Perhaps if you consider Karl as the upstream developer for setools and remember that these tools are intended to work on other distributions as well, it would be appropriate to not use /etc/sysconfig/selinux. Also, consider current practice where /etc/security/selinux/src is the location for the policysources thus selinux/src should contain /src/policy-x, policy-y and policy-z with /src/policy a link to any one of the policy-n directories as Karl suggested. Using /selinux/targeted/src and /selinux/foo/src and /selinux/whatever/src to contain different instances of source seems backward to me. (IMHO) :) Thanks, Richard Hally From aleksey at nogin.org Wed May 12 21:34:08 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Wed, 12 May 2004 14:34:08 -0700 Subject: policy and policy-source confusion In-Reply-To: <1084379683.4746.73.camel@athlon.localdomain> References: <1084197844.4753.38.camel@athlon.localdomain> <20040510143158.GQ9828@redhat.com> <40A11DB1.1030507@mindspring.com> <1084321202.4754.17.camel@athlon.localdomain> <1084379683.4746.73.camel@athlon.localdomain> Message-ID: <40A29850.1000306@nogin.org> On 12.05.2004 09:34, Leonard den Ottolander wrote: >>In my opinion installing/updating one package shouldn't modify files >>belonging to another package. If policy-source is going to do this it >>should be a specific action by the user post-installation, not a part of >>the installation process itself. > > > I thought I saw this in bugzilla, but can't find it. Maybe on IRC? > Thread on fedora-test/-devel? Dunno. Anyway, there are others who think > policy and policy-sources should mutually exclude each other. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118604 -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From mike at flyn.org Wed May 12 22:04:38 2004 From: mike at flyn.org (W. Michael Petullo) Date: Wed, 12 May 2004 17:04:38 -0500 Subject: Pam_selinux behavior incorrect? Message-ID: <20040512220438.GA4618@imp.flyn.org> I am very interested in hearing opinions/input on the following bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121650 To summarize: The su command, included in the coreutils package, does not interact with pam_selinux correctly. Su calls pam_open_session before forking to create a user's shell. Since pam_selinux is executed before forking, the SELinux domain of both the user's shell and the parent su process are modified. The result of this is that any PAM modules that are run by pam_close_session when the user logs out are executed with the user's SELinux security context instead of su's (user_t vs. user_su_t). The catch-22 is that if pam_open_session is called by the child after the fork then the parent's pam_close_session with have no knowlege that there is an open session. This all contradicts with how su treats traditional Unix UID handling. Su changes its UIDs to the user after it forks so that the parent su process continues to execute as root. The result of this is that, when using the traditional Unix security model, modules executed by pam_close_session have root privileges. I would argue that this is the correct behavior. I think /bin/login is in the same boat. -- Mike :wq From sds at epoch.ncsc.mil Thu May 13 11:44:52 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 13 May 2004 07:44:52 -0400 Subject: Pam_selinux behavior incorrect? In-Reply-To: <20040512220438.GA4618@imp.flyn.org> References: <20040512220438.GA4618@imp.flyn.org> Message-ID: <1084448692.14586.22.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-05-12 at 18:04, W. Michael Petullo wrote: > I am very interested in hearing opinions/input on the following bug: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121650 > > To summarize: > > The su command, included in the coreutils package, does not interact > with pam_selinux correctly. Su calls pam_open_session before forking > to create a user's shell. Since pam_selinux is executed before > forking, the SELinux domain of both the user's shell and the parent su > process are modified. The result of this is that any PAM modules that > are run by pam_close_session when the user logs out are executed with > the user's SELinux security context instead of su's (user_t vs. > user_su_t). > > The catch-22 is that if pam_open_session is called by the child after > the fork then the parent's pam_close_session with have no knowlege > that there is an open session. > > This all contradicts with how su treats traditional Unix UID handling. > Su changes its UIDs to the user after it forks so that the parent su > process continues to execute as root. The result of this is that, > when using the traditional Unix security model, modules executed by > pam_close_session have root privileges. I would argue that this is the > correct behavior. > > I think /bin/login is in the same boat. IIRC, on pam_open_session, pam_selinux sets the exec context for the process to the appropriate context for the user, so that any subsequently executed programs will transition into that context. On pam_close_session, pam_selinux restores the exec context to its original value, so any subsequently executed programs will revert to the prior behavior. The principal concern seems to be the impact on helper programs executed by other pam session modules invoked after pam_selinux when opening a session, and the impact on helper programs executed by other pam session modules invoked before pam_selinux when closing a session, as any such helper programs will end up in the user's context. Note that we originally directly patched programs like login and sshd for SELinux, but migrated to pam_selinux when Dan created it as a less invasive alternative. But perhaps there is a fundamental mismatch between the PAM interface and our desired functionality? We've raised that issue in the past, as pam is not presently used to set uids, but it seems unfortunate to have to patch every such program for SELinux. -- Stephen Smalley National Security Agency From taylors43 at comcast.net Thu May 13 12:46:00 2004 From: taylors43 at comcast.net (John Taylor) Date: Thu, 13 May 2004 08:46:00 -0400 Subject: The results of your email commands In-Reply-To: Message-ID: Please remove me from this mailing list - unsubscribe. Thanks you. -----Original Message----- From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list-bounces at redhat.com] Sent: Thursday, May 13, 2004 8:38 AM To: taylors43 at comcast.net Subject: The results of your email commands The results of your email command are provided below. Attached is your original message. - Results: Invalid confirmation string. Note that confirmation strings expire approximately 3 days after the initial subscription request. If your confirmation has expired, please try to re-submit your original request or message. - Unprocessed: Please remove me from this mailing list - unsubscribe. Thanks you. -----Original Message----- From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list-bounces at redhat.com]On Behalf Of fedora-selinux-list-request at redhat.com Sent: Thursday, May 06, 2004 2:22 PM To: taylors43 at comcast.net Subject: confirm 0fe6795c1367127fee716b9729dfd5c7b7fc696c Mailing list subscription confirmation notice for mailing list fedora-selinux-list We have received a request for subscription of your email address, "taylors43 at comcast.net", to the fedora-selinux-list at redhat.com mailing list. To confirm that you want to be added to this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: http://www.redhat.com/mailman/confirm/fedora-selinux-list/0fe6795c1367127fee 716b9729dfd5c7b7fc696c Or include the following line -- and only the following line -- in a message to fedora-selinux-list-request at redhat.com: confirm 0fe6795c1367127fee716b9729dfd5c7b7fc696c Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional "Re:" text in the Subject: is okay). If you do not wish to be subscribed from this list, please simply disregard this message. If you think you are being maliciously subscribed to the list, or have any other questions, send them to fedora-selinux-list-owner at redhat.com. - Done. From kmacmillan at tresys.com Thu May 13 15:47:30 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Thu, 13 May 2004 11:47:30 -0400 Subject: policy packages In-Reply-To: <40A27C65.2030209@mindspring.com> Message-ID: <200405131547.i4DFlRSf019127@gotham.columbia.tresys.com> > >> Will there be any way to determine which policy is currently active? > >> Also, I > >> am concerned that the well known location for the policy source > >> (/etc/security/selinux/src/policy/) will go away and break tools that > >> expect > >> it. All of our tools are configurable, of course, but this change will > >> make > >> it hard to provide good configuration defaults. What about making > >> /etc/security/selinux/src/policy a symlink to the currently active > >> policy? > >> > >> Karl > >> > >> > > We could change a sym link. We were thinking of using > > /etc/sysconfig/selinux to specify which policy is in use, and where the > > directories are. Right now I am just trying to get the SRPM to build > > both policy groups. The only tools that should be affected are those > > that deal with the src dir, which is the SEtools. > > -- > Perhaps if you consider Karl as the upstream developer for setools and > remember that these tools are intended to work on other distributions as > well, it would be appropriate to not use /etc/sysconfig/selinux. > Also, consider current practice where /etc/security/selinux/src is the > location for the policysources thus selinux/src should contain > /src/policy-x, policy-y and policy-z with /src/policy a link to any one > of the policy-n directories as Karl suggested. > Using /selinux/targeted/src and /selinux/foo/src and > /selinux/whatever/src to contain different instances of source seems > backward to me. (IMHO) :) I agree with this - we need to be able to support as many distributions as possible and the /etc/security/selinux/src/policy directory has been used for many years as the default location for the source to the current policy (making it an easy way for us to provide that support). I think that this would be worthwhile to retain through symlinks. Additionally, I think it would be better for the strict, targeted, etc sources to remain under src as Richard suggested. When binary modules are added in /etc/security/selinux/modules it will be clearer if all of the source is under /etc/security/selinux/src. Karl Karl MacMillan Tresys Technology http://www.tresys.com (410)290-1411 ext 134 > Thanks, > Richard Hally > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From fedora at andrewfarris.com Thu May 13 17:24:46 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Thu, 13 May 2004 10:24:46 -0700 Subject: The results of your email commands In-Reply-To: References: Message-ID: <1084469086.14223.7.camel@CirithUngol> On Thu, 2004-05-13 at 08:46 -0400, John Taylor wrote: > Please remove me from this mailing list - unsubscribe. Thanks you. See the entry field and button "Unsubscribe or edit options" at the bottom of this page. http://www.redhat.com/mailman/listinfo/fedora-selinux-list From mike at flyn.org Fri May 14 03:34:20 2004 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 13 May 2004 22:34:20 -0500 Subject: Pam_selinux behavior incorrect? In-Reply-To: <1084448692.14586.22.camel@moss-spartans.epoch.ncsc.mil> References: <20040512220438.GA4618@imp.flyn.org> <1084448692.14586.22.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20040514033420.GA2887@imp.flyn.org> >> I am very interested in hearing opinions/input on the following bug: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121650 >> >> To summarize: >> >> The su command, included in the coreutils package, does not interact >> with pam_selinux correctly. Su calls pam_open_session before forking >> to create a user's shell. Since pam_selinux is executed before >> forking, the SELinux domain of both the user's shell and the parent su >> process are modified. The result of this is that any PAM modules that >> are run by pam_close_session when the user logs out are executed with >> the user's SELinux security context instead of su's (user_t vs. >> user_su_t). >> >> The catch-22 is that if pam_open_session is called by the child after >> the fork then the parent's pam_close_session with have no knowlege >> that there is an open session. >> >> This all contradicts with how su treats traditional Unix UID handling. >> Su changes its UIDs to the user after it forks so that the parent su >> process continues to execute as root. The result of this is that, >> when using the traditional Unix security model, modules executed by >> pam_close_session have root privileges. I would argue that this is the >> correct behavior. >> >> I think /bin/login is in the same boat. > > IIRC, on pam_open_session, pam_selinux sets the exec context for the > process to the appropriate context for the user, so that any > subsequently executed programs will transition into that context. On > pam_close_session, pam_selinux restores the exec context to its original > value, so any subsequently executed programs will revert to the prior > behavior. The principal concern seems to be the impact on helper > programs executed by other pam session modules invoked after pam_selinux > when opening a session, and the impact on helper programs executed by > other pam session modules invoked before pam_selinux when closing a > session, as any such helper programs will end up in the user's context. Here is the new dilemma: Imagine a module, call it pam_foo, that requires special privileges to properly open and close a user's session. Currently, one has two basic configuration options: session pam_foo ... session pam_selinux ... or session pam_selinux ... session pam_foo ... In the former, pam_foo will not have the needed privileges when the session is to be closed (pam_selinux has not restored them yet). In the latter, pam_foo will not have the privileges needed to open the session (pam_selinux has already taken them away). One possible solution would be to modify PAM to invert the order in which modules are executed by pam_close_session. This seems to make sense conceptually but I am not sure if this would be a violation of the PAM standard. At first I really liked the idea of doing this SELinux magic with PAM, but now I am not so sure. As Stephen pointed out, the traditional Unix UID changes are not done using PAM. -- Mike :wq From mike at flyn.org Fri May 14 16:09:07 2004 From: mike at flyn.org (mike at flyn.org) Date: Fri, 14 May 2004 11:09:07 -0500 Subject: Pam_selinux behavior incorrect? Message-ID: <20040514150907.25856315C7@neuromancer.voxel.net> >>> I am very interested in hearing opinions/input on the following bug: >>> >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121650 >>> >>> To summarize: >>> >>> The su command, included in the coreutils package, does not interact >>> with pam_selinux correctly. Su calls pam_open_session before forking >>> to create a user's shell. Since pam_selinux is executed before >>> forking, the SELinux domain of both the user's shell and the parent su >>> process are modified. The result of this is that any PAM modules that >>> are run by pam_close_session when the user logs out are executed with >>> the user's SELinux security context instead of su's (user_t vs. >>> user_su_t). >>> >>> The catch-22 is that if pam_open_session is called by the child after >>> the fork then the parent's pam_close_session with have no knowlege >>> that there is an open session. >>> >>> This all contradicts with how su treats traditional Unix UID handling. >>> Su changes its UIDs to the user after it forks so that the parent su >>> process continues to execute as root. The result of this is that, >>> when using the traditional Unix security model, modules executed by >>> pam_close_session have root privileges. I would argue that this is the >>> correct behavior. >>> >>> I think /bin/login is in the same boat. >> IIRC, on pam_open_session, pam_selinux sets the exec context for the >> process to the appropriate context for the user, so that any >> subsequently executed programs will transition into that context. On >> pam_close_session, pam_selinux restores the exec context to its original >> value, so any subsequently executed programs will revert to the prior >> behavior. The principal concern seems to be the impact on helper >> programs executed by other pam session modules invoked after pam_selinux >> when opening a session, and the impact on helper programs executed by >> other pam session modules invoked before pam_selinux when closing a >> session, as any such helper programs will end up in the user's context. > Here is the new dilemma: > > Imagine a module, call it pam_foo, that requires special privileges > to properly open and close a user's session. Currently, one has two > basic configuration options: > > session pam_foo ... > session pam_selinux ... > > or > > session pam_selinux ... > session pam_foo ... > > In the former, pam_foo will not have the needed privileges when the > session is to be closed (pam_selinux has not restored them yet). In the > latter, pam_foo will not have the privileges needed to open the session > (pam_selinux has already taken them away). > > One possible solution would be to modify PAM to invert the order in > which modules are executed by pam_close_session. This seems to make > sense conceptually but I am not sure if this would be a violation of > the PAM standard. > > At first I really liked the idea of doing this SELinux magic with PAM, > but now I am not so sure. As Stephen pointed out, the traditional Unix > UID changes are not done using PAM. Here is another possible solution: break pam_selinux into pam_selinux_open and pam_selinux_close. Pam_selinux_open provide pam_open_session functionality and pam_selinux_close would handle pam_close_session. This would allow one to do something like this: session pam_selinux_close ... session pam_foo ... session pam_selinux_open ... The problem is you basically must have written a module yourself to understand PAM enough for this to be intuitive! Just another suggestion. -- Mike From russell at coker.com.au Sat May 15 03:01:57 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 15 May 2004 13:01:57 +1000 Subject: policy packages In-Reply-To: <40A27C65.2030209@mindspring.com> References: <200405121450.i4CEoZSf011818@gotham.columbia.tresys.com> <40A23F2B.9060909@redhat.com> <40A27C65.2030209@mindspring.com> Message-ID: <200405151301.57090.russell@coker.com.au> On Thu, 13 May 2004 05:35, Richard Hally wrote: > Also, consider current practice where /etc/security/selinux/src is the > location for the policysources thus selinux/src should contain > /src/policy-x, policy-y and policy-z with /src/policy a link to any one I think we should use /etc/selinux as the sym-link to the policy source. /etc/security/selinux/src is too much typing when you do any serious policy work. Dan, what do you think? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From kmacmillan at tresys.com Sat May 15 17:41:34 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Sat, 15 May 2004 13:41:34 -0400 Subject: policy packages References: <200405121450.i4CEoZSf011818@gotham.columbia.tresys.com><40A23F2B.9060909@redhat.com> <40A27C65.2030209@mindspring.com> <200405151301.57090.russell@coker.com.au> Message-ID: <003001c43aa3$de242ed0$0101a8c0@DESKTOP> ----- Original Message ----- From: "Russell Coker" To: Cc: "Daniel J Walsh" Sent: Friday, May 14, 2004 11:01 PM Subject: Re: policy packages > On Thu, 13 May 2004 05:35, Richard Hally wrote: > > Also, consider current practice where /etc/security/selinux/src is the > > location for the policysources thus selinux/src should contain > > /src/policy-x, policy-y and policy-z with /src/policy a link to any one > > I think we should use /etc/selinux as the sym-link to the policy > source. /etc/security/selinux/src is too much typing when you do any serious > policy work. > I am not against adding the symlink if /etc/security/selinux/src/policy remains. Breaking that compatibility will be a problem for us and others at least in the short term and, if other distributions don't adopt the change, a problem in the long term. All of our tools are easily configurable to find the policy source wherever, but this makes it difficult to set defaults. Also, I haven't seen what I thought was a compelling reason to break what has been standard practice for a long time. If you do want to add a shorter symlink, I think that it should be from /etc/security/selinux to /etc/selinux so that in the future /etc/selinux/src and /etc/selinux/modules can work nicely. Karl > Dan, what do you think? > > -- > http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages > http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark > http://www.coker.com.au/postal/ Postal SMTP/POP benchmark > http://www.coker.com.au/~russell/ My home page > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > From russell at coker.com.au Sat May 15 20:16:30 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 16 May 2004 06:16:30 +1000 Subject: policy packages In-Reply-To: <003001c43aa3$de242ed0$0101a8c0@DESKTOP> References: <200405121450.i4CEoZSf011818@gotham.columbia.tresys.com> <200405151301.57090.russell@coker.com.au> <003001c43aa3$de242ed0$0101a8c0@DESKTOP> Message-ID: <200405160616.30753.russell@coker.com.au> On Sun, 16 May 2004 03:41, "Karl MacMillan" wrote: > > I think we should use /etc/selinux as the sym-link to the policy > > source. /etc/security/selinux/src is too much typing when you do any > > serious policy work. > > I am not against adding the symlink if /etc/security/selinux/src/policy > remains. Breaking that compatibility will be a problem for us and others > at least in the short term and, if other distributions don't adopt the > change, a problem in the long term. All of our tools are easily If /etc/selinux is used then it's best for compatibility for everyone. Debian has been using /usr/share/selinux/policy/current since Howard suggested it: http://marc.theaimsgroup.com/?l=selinux&m=101864307520785&w=2 Gentoo apparently uses /etc/security/selinux/src/policy. It seems that if you want to have cross-distribution compatibility then a /etc/selinux sym-link is the best possibility. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From skywebsys at tiscali.it Mon May 17 21:06:51 2004 From: skywebsys at tiscali.it (skyweb) Date: Mon, 17 May 2004 23:06:51 +0200 Subject: How to disable SELinux on FC2(Test3) In-Reply-To: <4094D94E.7030308@tiscali.it> References: <4094D94E.7030308@tiscali.it> Message-ID: <40A9296B.5040302@tiscali.it> skywebsy wrote: > as subject, thanks selinux=0 at append line From kmacmillan at tresys.com Tue May 18 21:01:04 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Tue, 18 May 2004 17:01:04 -0400 Subject: policy packages In-Reply-To: <200405160616.30753.russell@coker.com.au> Message-ID: <200405182100.i4IL0wSf027360@gotham.columbia.tresys.com> > -----Original Message----- > From: Russell Coker [mailto:russell at coker.com.au] > Sent: Saturday, May 15, 2004 4:17 PM > To: Karl MacMillan > Cc: Fedora SELinux support list for users & developers.; Daniel J Walsh > Subject: Re: policy packages > > On Sun, 16 May 2004 03:41, "Karl MacMillan" wrote: > > > I think we should use /etc/selinux as the sym-link to the policy > > > source. /etc/security/selinux/src is too much typing when you do any > > > serious policy work. > > > > I am not against adding the symlink if /etc/security/selinux/src/policy > > remains. Breaking that compatibility will be a problem for us and > others > > at least in the short term and, if other distributions don't adopt the > > change, a problem in the long term. All of our tools are easily > > If /etc/selinux is used then it's best for compatibility for everyone. > > Debian has been using /usr/share/selinux/policy/current since Howard > suggested > it: > http://marc.theaimsgroup.com/?l=selinux&m=101864307520785&w=2 > > Gentoo apparently uses /etc/security/selinux/src/policy. It seems that if > you > want to have cross-distribution compatibility then a /etc/selinux sym-link > is > the best possibility. That is my goal, and I am glad that you mentioned that there are already problems with this. It seems like we still haven't solved the problem, though. I was after a consistent location for the currently active source and linking /etc/selinux /etc/security/selinux doesn't address this. I suggest that wherever the top of the selinux files is, the current policy should be in src/policy. That way /etc/selinux/src/policy would be the current policy source in your suggestion and the binary modules can then be /etc/selinux/modules. Karl Karl MacMillan Tresys Technology http://www.tresys.com (410)290-1411 ext 134 > > -- > http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages > http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark > http://www.coker.com.au/postal/ Postal SMTP/POP benchmark > http://www.coker.com.au/~russell/ My home page From gbpeck at sbcglobal.net Wed May 19 02:22:49 2004 From: gbpeck at sbcglobal.net (Gary Peck) Date: Tue, 18 May 2004 19:22:49 -0700 Subject: restorecon vs. setfiles Message-ID: <20040519022249.GC3717@realify.com> For some reason restorecon and setfiles have different notions of what context certain files should be. For example: # ls -Z /usr/lib/libz.* -rwxr-xr-x+ root root system_u:object_r:lib_t /usr/lib/libz.a lrwxrwxrwx+ root root system_u:object_r:lib_t /usr/lib/libz.so -> libz.so.1.2.1.1 lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libz.so.1 -> libz.so.1.2.1.1 -rwxr-xr-x root root system_u:object_r:shlib_t /usr/lib/libz.so.1.2.1.1 # restorecon -v /usr/lib/libz.* restorecon set context /usr/lib/libz.so->system_u:object_r:shlib_t restorecon set context /usr/lib/libz.so.1->system_u:object_r:shlib_t # setfiles -v /etc/security/selinux/file_contexts /usr/lib/libz.* setfiles: read 1450 specifications setfiles: labeling files under /usr/lib/libz.a setfiles: hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1 setfiles: labeling files under /usr/lib/libz.so setfiles: relabeling /usr/lib/libz.so from system_u:object_r:shlib_t to system_u:object_r:lib_t setfiles: hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1 setfiles: labeling files under /usr/lib/libz.so.1 setfiles: relabeling /usr/lib/libz.so.1 from system_u:object_r:shlib_t to system_u:object_r:lib_t setfiles: hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1 setfiles: labeling files under /usr/lib/libz.so.1.2.1.1 setfiles: hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1 setfiles: Done. So, restorecon thinks that *.so files should be shlib_t, whereas setfiles thinks they should be lib_t. Which one is right and why do they disagree? I thought that they both get their context info from the same place. This is with policy-1.11.3-5 and policycoreutils-1.11-4. gary From aleksey at nogin.org Wed May 19 03:05:16 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Tue, 18 May 2004 20:05:16 -0700 Subject: restorecon vs. setfiles In-Reply-To: <20040519022249.GC3717@realify.com> References: <20040519022249.GC3717@realify.com> Message-ID: <40AACEEC.4040805@nogin.org> On 18.05.2004 19:22, Gary Peck wrote: > For some reason restorecon and setfiles have different notions of what > context certain files should be. For example: [...] > So, restorecon thinks that *.so files should be shlib_t, whereas > setfiles thinks they should be lib_t. Which one is right and why do they > disagree? I thought that they both get their context info from the same > place. It seems the two disagree on symlinks. May be restorecon forgets to check whether its argument is a symlink? -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From dwalsh at redhat.com Wed May 19 03:07:54 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 18 May 2004 23:07:54 -0400 Subject: restorecon vs. setfiles In-Reply-To: <40AACEEC.4040805@nogin.org> References: <20040519022249.GC3717@realify.com> <40AACEEC.4040805@nogin.org> Message-ID: <40AACF8A.7010407@redhat.com> Aleksey Nogin wrote: > On 18.05.2004 19:22, Gary Peck wrote: > >> For some reason restorecon and setfiles have different notions of what >> context certain files should be. For example: > > [...] > >> So, restorecon thinks that *.so files should be shlib_t, whereas >> setfiles thinks they should be lib_t. Which one is right and why do they >> disagree? I thought that they both get their context info from the same >> place. > > > It seems the two disagree on symlinks. May be restorecon forgets to > check whether its argument is a symlink? > Looks like a bug in matchpathcon (Which is used buy restorecon). It is returning the wrong security context. I will send this to stephen. Basically looks like it is ignoring file type. Dan From dwalsh at redhat.com Wed May 19 03:15:20 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 18 May 2004 23:15:20 -0400 Subject: policy packages In-Reply-To: <200405182100.i4IL0wSf027360@gotham.columbia.tresys.com> References: <200405182100.i4IL0wSf027360@gotham.columbia.tresys.com> Message-ID: <40AAD148.3090207@redhat.com> Policy rename dilemma. I have a version of policy ready to go that supports both strict and targeted policy. The version I wrote creates targeted policy as policy and policy-sources and the strict as policy-strict and policy-strict-sources. The problem with this is that if I put it in Rawhide people upgrading will switch from strict policy to relaxed and require a relabel. If I change it to strict equals policy and policy-sources, with policy-targeted and policy-targeted-sources, than I am stuck with that even though policy-targeted will be the default in FC3, which seems wrong. Comments? Dan From katzj at redhat.com Wed May 19 03:31:31 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 18 May 2004 23:31:31 -0400 Subject: policy packages In-Reply-To: <40AAD148.3090207@redhat.com> References: <200405182100.i4IL0wSf027360@gotham.columbia.tresys.com> <40AAD148.3090207@redhat.com> Message-ID: <1084937491.2681.126.camel@bree.local.net> On Tue, 2004-05-18 at 23:15 -0400, Daniel J Walsh wrote: > Policy rename dilemma. I have a version of policy ready to go that > supports both strict and targeted policy. The version I wrote creates > targeted policy as policy and policy-sources and the strict as > policy-strict and policy-strict-sources. The problem with this is that > if I put it in Rawhide people upgrading will switch from strict policy > to relaxed and require a relabel. If I change it to strict equals > policy and policy-sources, with policy-targeted and > policy-targeted-sources, than I am stuck with that even though > policy-targeted will be the default in FC3, which seems wrong. You could do policy-strict Obsoletes: policy < newver. Then if you do an update with obsoletes/upgrade, you'll get policy-strict (and probably newer now targeted policy too, but having that installed doesn't cause problems) and the logic for what the various things in /etc/sysconfig/selinux are can be basically enabled ==> policy-strict targeted ==> policy (the targeted version) >From a packaging perspective, it should work. It's still a little confusing. I'd actually probably change the default for strict to be use strict instead of enabled and just have enabled for compatibility's sake. Jeremy From cturner at redhat.com Wed May 19 03:38:14 2004 From: cturner at redhat.com (Chip Turner) Date: Tue, 18 May 2004 23:38:14 -0400 Subject: policy packages In-Reply-To: <1084937491.2681.126.camel@bree.local.net> (Jeremy Katz's message of "Tue, 18 May 2004 23:31:31 -0400") References: <200405182100.i4IL0wSf027360@gotham.columbia.tresys.com> <40AAD148.3090207@redhat.com> <1084937491.2681.126.camel@bree.local.net> Message-ID: Jeremy Katz writes: > On Tue, 2004-05-18 at 23:15 -0400, Daniel J Walsh wrote: >> Policy rename dilemma. I have a version of policy ready to go that >> supports both strict and targeted policy. The version I wrote creates >> targeted policy as policy and policy-sources and the strict as >> policy-strict and policy-strict-sources. The problem with this is that >> if I put it in Rawhide people upgrading will switch from strict policy >> to relaxed and require a relabel. If I change it to strict equals >> policy and policy-sources, with policy-targeted and >> policy-targeted-sources, than I am stuck with that even though >> policy-targeted will be the default in FC3, which seems wrong. > > You could do policy-strict Obsoletes: policy < newver. Then if you do I tried versioned obsoletes with some Perl packaging for a while and, IIRC, rpm ignored the version completely. Or maybe it was up2date that did. Something handled it wrong, don't recall the details but the net result was 'doctor, it hurts when I do this. 'don't do that.' It may be fixed now, but this wasn't too far back. Chip -- Chip Turner cturner at redhat.com Red Hat, Inc. From rhally at mindspring.com Wed May 19 04:55:41 2004 From: rhally at mindspring.com (Richard Hally) Date: Wed, 19 May 2004 00:55:41 -0400 Subject: policy packages In-Reply-To: <40AAD148.3090207@redhat.com> References: <200405182100.i4IL0wSf027360@gotham.columbia.tresys.com> <40AAD148.3090207@redhat.com> Message-ID: <40AAE8CD.3040101@mindspring.com> Daniel J Walsh wrote: > Policy rename dilemma. I have a version of policy ready to go that > supports both strict and targeted policy. The version I wrote creates > targeted policy as policy and policy-sources and the strict as > policy-strict and policy-strict-sources. The problem with this is that > if I put it in Rawhide people upgrading will switch from strict policy > to relaxed and require a relabel. If I change it to strict equals > policy and policy-sources, with policy-targeted and > policy-targeted-sources, than I am stuck with that even though > policy-targeted will be the default in FC3, which seems wrong. > Comments? > > Dan > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > If "targeted" will be the default going forward, it seems that the thing to do is make the change now. A one time relabel at this stage is not as bad as having to make a switch later. For those that want the "strict" , they can set up the links the way they prefer after the update. Is the "strict" policy close to what is now in place? Richard Hally From mikkel at linet.dk Wed May 19 10:55:50 2004 From: mikkel at linet.dk (Mikkel Kruse Johnsen) Date: Wed, 19 May 2004 12:55:50 +0200 Subject: Running under diff. accounts or using SELinux Message-ID: <1084964150.4171.6.camel@tux.lib.cbs.dk> Hi All What is the relation between a process running under a system account or under domains ? Are these co-existing or can SELinux domains replace system accounts ? Ex. can apache just use "root" as system account and use domains to rescrict it ? Meaning do we need to have all these system account or can SELinux get rid of them ? Qmail is using 7 diff. system account, can I with SELinux just use "root" and have SELinux do the security !!! /Mikkel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at epoch.ncsc.mil Wed May 19 12:09:42 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 19 May 2004 08:09:42 -0400 Subject: restorecon vs. setfiles In-Reply-To: <40AACF8A.7010407@redhat.com> References: <20040519022249.GC3717@realify.com> <40AACEEC.4040805@nogin.org> <40AACF8A.7010407@redhat.com> Message-ID: <1084968582.30873.3.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2004-05-18 at 23:07, Daniel J Walsh wrote: > Looks like a bug in matchpathcon (Which is used buy restorecon). It is > returning the wrong security context. I will send this to stephen. > Basically looks like it is ignoring file type. matchpathcon takes a pathname and optional file mode as input parameters for matching against the file contexts configuration. It doesn't attempt to stat the file itself to obtain the mode because it is sometimes used by programs that are creating new files (e.g. udev) and want to know the context for the file they are about to create, so it requires the caller to provide the mode. restorecon currently passes 0 as the mode, so no mode matching is performed. So this is a bug in restorecon; it needs to be changed to stat the file and provide the mode. -- Stephen Smalley National Security Agency From walters at redhat.com Wed May 19 12:32:03 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 19 May 2004 08:32:03 -0400 Subject: Running under diff. accounts or using SELinux In-Reply-To: <1084964150.4171.6.camel@tux.lib.cbs.dk> References: <1084964150.4171.6.camel@tux.lib.cbs.dk> Message-ID: <1084969923.13503.2.camel@nexus.verbum.private> On Wed, 2004-05-19 at 06:55, Mikkel Kruse Johnsen wrote: > Hi All > > What is the relation between a process running under a system account > or under domains ? There's almost no relation. However SELinux does have a concept of "user identity" that is derived from the system accounts. The SELinux user identity is restricted to a set of roles, each of which stands for a set of domains. Thus there is a relationship, but not a very direct or strong one :) In the cases you talk about though, typically you wouldn't have a SELinux user defined. > Are these co-existing or can SELinux domains replace system accounts ? Completely coexisting. > Ex. can apache just use "root" as system account and use domains to > rescrict it ? Yes. > Meaning do we need to have all these system account or can SELinux get > rid of them ? > > Qmail is using 7 diff. system account, can I with SELinux just use > "root" and have SELinux do the security !!! Yes. It's not recommended though - why throw away a level of security? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwalsh at redhat.com Wed May 19 18:58:09 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 19 May 2004 14:58:09 -0400 Subject: policy packages In-Reply-To: <40AAE8CD.3040101@mindspring.com> References: <200405182100.i4IL0wSf027360@gotham.columbia.tresys.com> <40AAD148.3090207@redhat.com> <40AAE8CD.3040101@mindspring.com> Message-ID: <40ABAE41.10906@redhat.com> Richard Hally wrote: > Daniel J Walsh wrote: > >> Policy rename dilemma. I have a version of policy ready to go that >> supports both strict and targeted policy. The version I wrote >> creates targeted policy as policy and policy-sources and the strict >> as policy-strict and policy-strict-sources. The problem with this is >> that if I put it in Rawhide people upgrading will switch from strict >> policy to relaxed and require a relabel. If I change it to strict >> equals policy and policy-sources, with policy-targeted and >> policy-targeted-sources, than I am stuck with that even though >> policy-targeted will be the default in FC3, which seems wrong. >> Comments? >> >> Dan >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > If "targeted" will be the default going forward, it seems that the > thing to do is make the change now. A one time relabel at this stage > is not as bad as having to make a switch later. > For those that want the "strict" , they can set up the links the way > they prefer after the update. > Is the "strict" policy close to what is now in place? Strict is the current policy with several fixes. Dan > > Richard Hally > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Wed May 19 19:17:50 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 19 May 2004 15:17:50 -0400 Subject: restorecon vs. setfiles In-Reply-To: <1084968582.30873.3.camel@moss-spartans.epoch.ncsc.mil> References: <20040519022249.GC3717@realify.com> <40AACEEC.4040805@nogin.org> <40AACF8A.7010407@redhat.com> <1084968582.30873.3.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <40ABB2DE.5090107@redhat.com> Stephen Smalley wrote: >On Tue, 2004-05-18 at 23:07, Daniel J Walsh wrote: > > >>Looks like a bug in matchpathcon (Which is used buy restorecon). It is >>returning the wrong security context. I will send this to stephen. >>Basically looks like it is ignoring file type. >> >> > >matchpathcon takes a pathname and optional file mode as input parameters >for matching against the file contexts configuration. It doesn't >attempt to stat the file itself to obtain the mode because it is >sometimes used by programs that are creating new files (e.g. udev) and >want to know the context for the file they are about to create, so it >requires the caller to provide the mode. restorecon currently passes 0 >as the mode, so no mode matching is performed. > >So this is a bug in restorecon; it needs to be changed to stat the file >and provide the mode. > > > policycoreutils-1.12-2 has two fixes for restorecon, it handles the symbolic link problem and ignores <>. Dan From katzj at redhat.com Wed May 19 19:52:02 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 19 May 2004 15:52:02 -0400 Subject: policy packages In-Reply-To: References: <200405182100.i4IL0wSf027360@gotham.columbia.tresys.com> <40AAD148.3090207@redhat.com> <1084937491.2681.126.camel@bree.local.net> Message-ID: <1084996322.6803.10.camel@bree.local.net> On Tue, 2004-05-18 at 23:38 -0400, Chip Turner wrote: > I tried versioned obsoletes with some Perl packaging for a while and, > IIRC, rpm ignored the version completely. Or maybe it was up2date > that did. Something handled it wrong, don't recall the details but > the net result was 'doctor, it hurts when I do this. 'don't do that.' > It may be fixed now, but this wasn't too far back. RPM does the right thing. There may be tools that don't, but if that's the case, my response is "fix the bloody tool". Avoiding it just means that it'll never get fixed :) Jeremy From pmehta at wideopenwest.com Fri May 21 05:30:38 2004 From: pmehta at wideopenwest.com (Pratik Mehta) Date: Fri, 21 May 2004 00:30:38 -0500 Subject: FC2test3 and final release In-Reply-To: <1084996322.6803.10.camel@bree.local.net> References: <200405182100.i4IL0wSf027360@gotham.columbia.tresys.com> <40AAD148.3090207@redhat.com> <1084937491.2681.126.camel@bree.local.net> <1084996322.6803.10.camel@bree.local.net> Message-ID: <40AD93FE.5050600@wideopenwest.com> hi, is there a difference between the two releases: FC2 Test 3 and the Final fedora release, as far as SELinux goes. - Pratik PS: sorry message is in html, will need to fix this mail app. From wolfy at pcnet.ro Fri May 21 16:28:37 2004 From: wolfy at pcnet.ro (lonely wolf) Date: Fri, 21 May 2004 16:28:37 +0000 Subject: policy packages In-Reply-To: <40AAD148.3090207@redhat.com> References: <200405182100.i4IL0wSf027360@gotham.columbia.tresys.com> <40AAD148.3090207@redhat.com> Message-ID: <40AE2E35.8070202@pcnet.ro> Daniel J Walsh wrote: > Policy rename dilemma. I have a version of policy ready to go that > supports both strict and targeted policy. The version I wrote > creates targeted policy as policy and policy-sources and the strict as > policy-strict and policy-strict-sources. The problem with this is > that if I put it in Rawhide people upgrading will switch from strict > policy to relaxed and require a relabel. If I change it to strict > equals policy and policy-sources, with policy-targeted and > policy-targeted-sources, than I am stuck with that even though > policy-targeted will be the default in FC3, which seems wrong. > Comments? %pre echo make sure to relabel .... -- My mechanic told me, "I couldn't repair your brakes, so I made your horn louder." From sds at epoch.ncsc.mil Fri May 21 17:39:45 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 21 May 2004 13:39:45 -0400 Subject: FC2test3 and final release In-Reply-To: <40AD93FE.5050600@wideopenwest.com> References: <200405182100.i4IL0wSf027360@gotham.columbia.tresys.com> <40AAD148.3090207@redhat.com> <1084937491.2681.126.camel@bree.local.net> <1084996322.6803.10.camel@bree.local.net> <40AD93FE.5050600@wideopenwest.com> Message-ID: <1085161185.2789.160.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-05-21 at 01:30, Pratik Mehta wrote: > is there a difference between the two releases: > FC2 Test 3 and the Final fedora release, as far as SELinux goes. Yes, there have certainly been changes to SELinux-related packages since test3. But if you have been updating from the devel tree, you should be up-to-date. Note that even if you have installed FC2/final, there are newer packages in the devel tree relevant to SELinux, including SELinux-related changes to the kernel as well as updates to policy and the like. -- Stephen Smalley National Security Agency From selinux at comcast.net Fri May 21 18:16:09 2004 From: selinux at comcast.net (Tom London) Date: Fri, 21 May 2004 11:16:09 -0700 Subject: Suggested 'minor enhancement' to fixfiles.... Message-ID: <40AE4769.4070902@comcast.net> 'fixfiles relabel' cleans out /tmp, including log files from previous runs of fixfiles. (I had just run 'fixfiles check' and didn't expect to lose the log!). Also, 'fixfiles relabel' does not log changes.... Does it make sense to change the 'relabel()' fn in fixfiles from: relabel() { echo "Cleaning out /tmp" rm -rf /tmp/.??* /tmp/* ${SETFILES} ${FC} ${FILESYSTEMS} 2>&1 | tee $LOGFILE } to something like: relabel() { echo "Cleaning out /tmp (saving previous fixfiles logs)" find /tmp -maxdepth 1 -mindepth 1 | grep -v /tmp/fixfiles | xargs rm -rf ${SETFILES} -v ${FC} ${FILESYSTEMS} 2>&1 | tee $LOGFILE | grep -v "/usr/sbin/setfiles: relabeling" } This way the changes are logged (but not displayed on the console), and previous log files are retained. tom From selinux at comcast.net Fri May 21 20:30:37 2004 From: selinux at comcast.net (Tom London) Date: Fri, 21 May 2004 13:30:37 -0700 Subject: mailman, cron, /bin/sh (more on Re: restorecon vs. setfiles???) Message-ID: <40AE66ED.2050101@comcast.net> I did a FC2 install 'everything' and that seems to have turned on mailman cron entries. Unfortuneately, the one that runs /var/mailman/cron/gate_news (every 5 minutes!) fails and sends email to email with the report: Subject: Cron /usr/bin/python -S /var/mailman/cron/gate_news X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: execl: couldn't exec `/bin/sh' execl: Permission denied The equivalent avc message is: May 21 12:00:00 dell kernel: audit(1085166000.890:0): avc: denied { transition } for pid=7796 exe=/usr/sbin/crond path=/bin/bash dev=hdb3 ino=376840 scontext=system_u:system_r:crond_t tcontext=user_u:sysadm_r:sysadm_t tclass=process The appropriate entry in crond.te (I think) is: can_exec(crond_t, shell_exec_t) The labels for /bin/bash and /bin/sh are as follows (from a clean FC2 install): -rwxr-xr-x+ root root system_u:object_r:shell_exec_t bash lrwxrwxrwx+ root root system_u:object_r:bin_t sh -> bash Is the label for /bin/sh causing this to fail? tom ------------------------------------------------------------------------ * /From/: Daniel J Walsh * /To/: "Fedora SELinux support list for users & developers." * /Subject/: Re: restorecon vs. setfiles * /Date/: Wed, 19 May 2004 15:17:50 -0400 ------------------------------------------------------------------------ Stephen Smalley wrote: On Tue, 2004-05-18 at 23:07, Daniel J Walsh wrote: Looks like a bug in matchpathcon (Which is used buy restorecon). It is returning the wrong security context. I will send this to stephen. Basically looks like it is ignoring file type. matchpathcon takes a pathname and optional file mode as input parameters for matching against the file contexts configuration. It doesn't attempt to stat the file itself to obtain the mode because it is sometimes used by programs that are creating new files (e.g. udev) and want to know the context for the file they are about to create, so it requires the caller to provide the mode. restorecon currently passes 0 as the mode, so no mode matching is performed. So this is a bug in restorecon; it needs to be changed to stat the file and provide the mode. policycoreutils-1.12-2 has two fixes for restorecon, it handles the symbolic link problem and ignores <>. Dan From concert at europe.com Thu May 20 01:37:36 2004 From: concert at europe.com (t l) Date: Wed, 19 May 2004 17:37:36 -0800 Subject: FC2 install with 'selinux' fails.... Message-ID: <20040520013736.D4306101C3@ws1-16.us4.outblaze.com> I tried to install my shiny new FC2 CDs (verified!) 'on top of' an existing FC2T3/selinux=enabled system. I entered 'selinux' at the install/boot prompt. I tried both 'updating existing system' and a clean install on top of the existing partitions. After selecting packages and writing the install image to disk, both attempt produce an anaconda abort message saying OSError: [Errno 17] File exists: '/mnt/sysimage/selinux' I bugzilla'ed this against anaconda as the abort message requested (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123687), but I'm guessing that I missed something quite basic. Do I need to completely wipe the drive clean to proceed? Suggestions warmly welcomed. tom -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From concert at europe.com Fri May 21 01:02:31 2004 From: concert at europe.com (t l) Date: Thu, 20 May 2004 17:02:31 -0800 Subject: FC2 install botch/home directory not properly labelled... Message-ID: <20040521010231.B019479004A@ws1-14.us4.outblaze.com> I just did a fresh, clean install of FC2 with selinux enabled (in boot/install prompt). When completed (after install and firstboot finished), I could not login either as the user I created in firstboot or as root (both in graphical mode). The error reported that the home directory did not exist. I rebooted in single user mode and determined that the user's home directory was not properly labelled.... The directory and all files in it were labeled system_u:object_r:home_root_t I ran 'fixfiles relabel'. It correctly relabeled those (and other) files. So, either firstboot didn't do the labelling, or the labelling failed across a mount point (/home was mounted on /dev/hdb20), or I'm supposed to manually run fixfiles after install, or .... ? I filed a bugzilla against firstboot, but I'm not sure this is correct. (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123856) Thoughts? -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From concert at europe.com Fri May 21 16:49:53 2004 From: concert at europe.com (t l) Date: Fri, 21 May 2004 08:49:53 -0800 Subject: Suggested 'minor enhancement' to fixfiles ... ? Message-ID: <20040521164953.7C06679004A@ws1-14.us4.outblaze.com> 'fixfiles relabel' cleans out /tmp, including log files from previous runs of fixfiles. (I had just run 'fixfiles check' and didn't expect to lose the log!). Also, 'fixfiles relabel' does not log changes.... Does it make sense to change the 'relabel()' fn in fixfiles from: relabel() { echo "Cleaning out /tmp" rm -rf /tmp/.??* /tmp/* ${SETFILES} ${FC} ${FILESYSTEMS} 2>&1 | tee $LOGFILE } to something like: relabel() { echo "Cleaning out /tmp (saving previous fixfiles logs)" find /tmp -maxdepth 1 -mindepth 1 | grep -v /tmp/fixfiles | xargs rm -rf ${SETFILES} -v ${FC} ${FILESYSTEMS} 2>&1 | tee $LOGFILE | grep -v "/usr/sbin/setfiles: relabeling" } This way the changes are logged (but not displayed on the console), and previous log files are retained. tom -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From rhally at mindspring.com Fri May 21 23:29:35 2004 From: rhally at mindspring.com (Richard Hally) Date: Fri, 21 May 2004 19:29:35 -0400 Subject: FC2 install with 'selinux' fails.... In-Reply-To: <20040520013736.D4306101C3@ws1-16.us4.outblaze.com> References: <20040520013736.D4306101C3@ws1-16.us4.outblaze.com> Message-ID: <40AE90DF.3030202@mindspring.com> t l wrote: > I tried to install my shiny new FC2 CDs (verified!) 'on top of' an existing > FC2T3/selinux=enabled system. I entered 'selinux' at the install/boot prompt. > > I tried both 'updating existing system' and a clean install on top of the > existing partitions. After selecting packages and writing the install image > to disk, both attempt produce an anaconda abort message saying > OSError: [Errno 17] File exists: '/mnt/sysimage/selinux' > > I bugzilla'ed this against anaconda as the abort message requested > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123687), but > I'm guessing that I missed something quite basic. Do I need to > completely wipe the drive clean to proceed? > > Suggestions warmly welcomed. > tom > > I had the same problem. I went for a fresh install. One thing that may help is at the configure the firewall screen during the install, change the selinux option to 'warn'. HTH Richard Hally From gene at czarc.net Sat May 22 11:39:08 2004 From: gene at czarc.net (Gene Czarcinski) Date: Sat, 22 May 2004 07:39:08 -0400 Subject: Suggested 'minor enhancement' to fixfiles ... ? In-Reply-To: <20040521164953.7C06679004A@ws1-14.us4.outblaze.com> References: <20040521164953.7C06679004A@ws1-14.us4.outblaze.com> Message-ID: <200405220739.08457.gene@czarc.net> On Friday 21 May 2004 12:49, t l wrote: > 'fixfiles relabel' cleans out /tmp, including log files from previous > runs of fixfiles. (I had just run 'fixfiles check' and didn't expect > to lose the log!). > > Also, 'fixfiles relabel' does not log changes.... > > Does it make sense to change the 'relabel()' fn in fixfiles from: > relabel() { > echo "Cleaning out /tmp" > rm -rf /tmp/.??* /tmp/* > ${SETFILES} ${FC} ${FILESYSTEMS} 2>&1 | tee $LOGFILE > } > to something like: > relabel() { > echo "Cleaning out /tmp (saving previous fixfiles logs)" > find /tmp -maxdepth 1 -mindepth 1 | grep -v /tmp/fixfiles | xargs rm > -rf ${SETFILES} -v ${FC} ${FILESYSTEMS} 2>&1 | tee $LOGFILE | grep -v > "/usr/sbin/setfiles: relabeling" } > > This way the changes are logged (but not displayed on the console), and > previous log files are retained. > I suggest you file a bugzilla report to document this RFE ... that way it will not get lost. Gene From selinux at comcast.net Sat May 22 16:57:04 2004 From: selinux at comcast.net (Tom London) Date: Sat, 22 May 2004 09:57:04 -0700 Subject: Suggested 'minor enhancement' to fixfiles ... ? Message-ID: <40AF8660.9080400@comcast.net> Done: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123995 From Gene Czarcinski : I suggest you file a bugzilla report to document this RFE ... that way it will not get lost. Gene From sds at epoch.ncsc.mil Mon May 24 12:17:14 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 24 May 2004 08:17:14 -0400 Subject: mailman, cron, /bin/sh (more on Re: restorecon vs. setfiles???) In-Reply-To: <40AE66ED.2050101@comcast.net> References: <40AE66ED.2050101@comcast.net> Message-ID: <1085401034.26446.23.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-05-21 at 16:30, Tom London wrote: > I did a FC2 install 'everything' and that seems to have turned on mailman > cron entries. Unfortuneately, the one that runs /var/mailman/cron/gate_news > (every 5 minutes!) fails and sends email to email with the report: > May 21 12:00:00 dell kernel: audit(1085166000.890:0): avc: denied > { transition } for pid=7796 exe=/usr/sbin/crond path=/bin/bash > dev=hdb3 ino=376840 scontext=system_u:system_r:crond_t > tcontext=user_u:sysadm_r:sysadm_t tclass=process crond shouldn't be attempting to transition to sysadm_t for a cron job. getconlist user_u system_u:system_r:crond_t shows a default of user_u:user_r:user_crond_t. -- Stephen Smalley National Security Agency From t.pitt at eris.qinetiq.com Mon May 24 15:13:48 2004 From: t.pitt at eris.qinetiq.com (Anthony Pitt) Date: Mon, 24 May 2004 16:13:48 +0100 Subject: New user Message-ID: Hi there, I hope you can help. I've just installed 'Fedora COre2', with Selinux enabled. Using 'seuser' I created a new 'defined' selinux user, with user_r role only. I also created the users /home/* directory under the same process. I'm using the 'gnome' window manager interface. Now when I try to log on with this new user, I get all sorts of errors to do with the users environment, eventually allowing me a blank interface, with 'right-click' functionality only. Any ideas? Tony. ---------------------------------------------------------------------- A D Pitt Ph:+44(0)1684 895757 Rm B006 Woodward Building Fax:+44(0)1684 896660 QinetiQ email:t.pitt at eris.qinetiq.com Malvern Technology Centre, St Andrews Road Malvern Worcs. WR14 3PS URL:http://www.qinetiq.com/home_enterprise_security.html From sopwith at redhat.com Mon May 24 17:47:01 2004 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 24 May 2004 13:47:01 -0400 Subject: Fedora Project Mailing Lists reminder Message-ID: This is a reminder of the mailing lists for the Fedora Project, and the purpose of each list. You can view this information at http://fedora.redhat.com/participate/communicate/ When you're using these mailing lists, please take the time to choose the one that is most appropriate to your post. If you don't know the right mailing list to use for a question or discussion, please contact me. This will help you get the best possible answer for your question, and keep other list subscribers happy! Mailing Lists Mailing lists are email addresses which send email to all users subscribed to the mailing list. Sending an email to a mailing list reaches all users interested in discussing a specific topic and users available to help other users with the topic. The following mailing lists are available. To subscribe, send email to -request at redhat.com (replace with the desired mailing list name such as fedora-list) with the word subscribe in the subject. fedora-announce-list - Announcements of changes and events. To stay aware of news, subscribe to this list. fedora-list - For users of releases. If you want help with a problem installing or using , this is the list for you. fedora-test-list - For testers of test releases. If you would like to discuss experiences using TEST releases, this is the list for you. fedora-devel-list - For developers, developers, developers. If you are interested in helping create releases, this is the list for you. fedora-docs-list - For participants of the docs project fedora-desktop-list - For discussions about desktop issues such as user interfaces, artwork, and usability fedora-config-list - For discussions about the development of configuration tools fedora-legacy-announce - For announcements about the Fedora Legacy Project fedora-legacy-list - For discussions about the Fedora Legacy Project fedora-selinux-list - For discussions about the Fedora SELinux Project fedora-de-list - For discussions about Fedora in the German language fedora-ja-list - For discussions about Fedora in the Japanese language fedora-i18n-list - For discussions about the internationalization of Fedora Core fedora-trans-list - For discussions about translating the software and documentation associated with the Fedora Project German: fedora-trans-de French: fedora-trans-fr Spanish: fedora-trans-es Italian: fedora-trans-it Brazilian Portuguese: fedora-trans-pt_br Japanese: fedora-trans-ja Korean: fedora-trans-ko Simplified Chinese: fedora-trans-zh_cn Traditional Chinese: fedora-trans-zh_tw From bobgus at rcn.com Mon May 24 18:24:54 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Mon, 24 May 2004 13:24:54 -0500 Subject: New user In-Reply-To: Message-ID: You are further along .. I get [root at hoho2 user1]# date Mon May 24 13:16:52 CDT 2004 [root at hoho2 user1]# seuser show users Could not open policy.conf file [root at hoho2 user1]# I have FC2 installed clean with all updates (incl development) to this moment (except for ppp - which is having a problem independent of selinux). Booting with kernel boot parame 'selinux=1 enforcing=0' (not enforce=0..) The boot was done just after a run of '/sbin/fixfiles relabel' at init level 1. BobG On Mon, 24 May 2004 16:13:48 +0100, Anthony Pitt wrote: >Hi there, > I hope you can help. I've just installed 'Fedora COre2', with Selinux >enabled. >Using 'seuser' I created a new 'defined' selinux user, with user_r role >only. I also created the users /home/* directory under the same process. >I'm using the 'gnome' window manager interface. >Now when I try to log on with this new user, I get all sorts of errors to >do with the users environment, eventually allowing me a blank interface, >with 'right-click' functionality only. >Any ideas? >Tony. > >---------------------------------------------------------------------- >A D Pitt Ph:+44(0)1684 895757 >Rm B006 Woodward Building Fax:+44(0)1684 896660 >QinetiQ email:t.pitt at eris.qinetiq.com >Malvern Technology Centre, >St Andrews Road >Malvern >Worcs. >WR14 3PS > >URL:http://www.qinetiq.com/home_enterprise_security.html >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list From bobgus at rcn.com Mon May 24 18:33:08 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Mon, 24 May 2004 13:33:08 -0500 Subject: New user Message-ID: Some added information [root at hoho2 user1]# ls -lZ /etc/security/selinux/src/policy/policy.conf -rw-r--r--+ root root system_u:object_r:policy_src_t /etc/security/selinux/src/policy/policy.conf [root at hoho2 user1]# cat /proc/version Linux version 2.6.6-1.377smp (bhcompile at tweety.build.redhat.com) (gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)) #1 SMP Sat May 22 15:16:37 EDT 2004 [root at hoho2 user1]# which seuser /usr/bin/seuser [root at hoho2 user1]# ls -lZ /usr/bin/seuser -rwxr-xr-x+ root root system_u:object_r:bin_t /usr/bin/seuser [root at hoho2 user1]# ------- previously sent a minute or so ago -- You are further along .. I get [root at hoho2 user1]# date Mon May 24 13:16:52 CDT 2004 [root at hoho2 user1]# seuser show users Could not open policy.conf file [root at hoho2 user1]# I have FC2 installed clean with all updates (incl development) to this moment (except for ppp - which is having a problem independent of selinux). Booting with kernel boot parame 'selinux=1 enforcing=0' (not enforce=0..) The boot was done just after a run of '/sbin/fixfiles relabel' at init level 1. BobG On Mon, 24 May 2004 16:13:48 +0100, Anthony Pitt wrote: >Hi there, > I hope you can help. I've just installed 'Fedora COre2', with Selinux >enabled. >Using 'seuser' I created a new 'defined' selinux user, with user_r role >only. I also created the users /home/* directory under the same process. >I'm using the 'gnome' window manager interface. >Now when I try to log on with this new user, I get all sorts of errors to >do with the users environment, eventually allowing me a blank interface, >with 'right-click' functionality only. >Any ideas? >Tony. > >---------------------------------------------------------------------- >A D Pitt Ph:+44(0)1684 895757 >Rm B006 Woodward Building Fax:+44(0)1684 896660 >QinetiQ email:t.pitt at eris.qinetiq.com >Malvern Technology Centre, >St Andrews Road >Malvern >Worcs. >WR14 3PS > >URL:http://www.qinetiq.com/home_enterprise_security.html >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list From bobgus at rcn.com Mon May 24 18:43:39 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Mon, 24 May 2004 13:43:39 -0500 Subject: FC2 install with 'selinux' fails.... In-Reply-To: <40AE90DF.3030202@mindspring.com> References: <20040520013736.D4306101C3@ws1-16.us4.outblaze.com> <20040520013736.D4306101C3@ws1-16.us4.outblaze.com> Message-ID: I was also faced with the question - to 'Clean Install' or not. The pro consideration is that you have a completely known entity - no configuration files that are hanging around from the last tests. The con consideration is that you don't have old configuration (and other) files that you can look at and compare with the newly installed image. A compromise approach is to boot up another system, mount the fedora hard disk on that system, and create a directory /old and then move all of the directories in / to the /old directory (e.g. cd /; mv lib /old; mv usr /old, etc) on the fedora disk (assumes at least two disks, or weird partitions on one disk) The install of Fedora2 assumes you have enough disk space. If not, you can selectively delete directories in the /old directory. Doing 'rm -rf /old/lib' will cut the space required by the old system dramatically. After all of the directories have been moved or copied (if /boot is on a separate partition), then boot from FC2 install disk 1, format /boot and leave all of the other partitions 'as is'. This should give you a 'clean' FC2 system install. There have been updates since the base FC2 iso images were made, so try to do yum update \* You may have trouble with ppp - in that case, do yum --exclude=ppp update \* Good luck - I'm still not completely up with selinux. BobG ---- On Fri, 21 May 2004 19:29:35 -0400 Richard Hally wrote: >t l wrote: >> I tried to install my shiny new FC2 CDs (verified!) 'on top of' an existing >> FC2T3/selinux=enabled system. I entered 'selinux' at the install/boot >>prompt. >> >> I tried both 'updating existing system' and a clean install on top of the >> existing partitions. After selecting packages and writing the install image >> to disk, both attempt produce an anaconda abort message saying >> OSError: [Errno 17] File exists: '/mnt/sysimage/selinux' >> >> I bugzilla'ed this against anaconda as the abort message requested >> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123687), but >> I'm guessing that I missed something quite basic. Do I need to >> completely wipe the drive clean to proceed? >> >> Suggestions warmly welcomed. >> tom >> >> >I had the same problem. I went for a fresh install. One thing that may >help is at the configure the firewall screen during the install, change >the selinux option to 'warn'. >HTH >Richard Hally > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list From bball at tux.org Mon May 24 19:26:33 2004 From: bball at tux.org (billy ball) Date: Mon, 24 May 2004 15:26:33 -0400 (EDT) Subject: firstbook new user creation? In-Reply-To: <20040524160019.32DB374349@hormel.redhat.com> Message-ID: hi! cool distro! installed FC2 onto a dual-CPU P4 MPC box w/1GB RAM, 80GB SATA drive, DVD/CDRW drive... installed w/no problems (using selinux, enforced selection during install)... however, creating a new user using firstboot dialog doesn't work... my workaround was root login via Ctrl+Alt+F2, then role selection... known problem? From kmacmillan at tresys.com Mon May 24 21:33:24 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Mon, 24 May 2004 17:33:24 -0400 Subject: New user In-Reply-To: Message-ID: <200405242133.i4OLX8Sf030813@gotham.columbia.tresys.com> > -----Original Message----- > From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list- > bounces at redhat.com] On Behalf Of Bob Gustafson > Sent: Monday, May 24, 2004 2:33 PM > To: t.pitt at eris.qinetiq.com; Fedora SELinux support list for users & > developers. > Subject: Re: New user > > Some added information > > [root at hoho2 user1]# ls -lZ /etc/security/selinux/src/policy/policy.conf > -rw-r--r--+ root root > system_u:object_r:policy_src_t > /etc/security/selinux/src/policy/policy.conf > > [root at hoho2 user1]# cat /proc/version > Linux version 2.6.6-1.377smp (bhcompile at tweety.build.redhat.com) (gcc > version 3.3.3 20040412 (Red Hat > Linux 3.3.3-7)) #1 SMP Sat May 22 15:16:37 EDT 2004 > > [root at hoho2 user1]# which seuser > /usr/bin/seuser > > [root at hoho2 user1]# ls -lZ /usr/bin/seuser -rwxr-xr-x+ root root > system_u:object_r:bin_t > /usr/bin/seuser > [root at hoho2 user1]# > This is part of the problem - seuser runs in its own domain so the binary needs to be labeled seuser_exec_t. Unfortunately it looks like seuser is quite broken on FC2. You can fix it by: 1) mv /etc/security/selinux/src/policy/domains/program/unused/seuser.te to etc/security/selinux/src/policy/domains/program/seuser.te. 2) edit /etc/security/selinux/src/policy/file_contexts/programs/seuser.fc changing "/usr/apol/seuser.conf" to "/usr/share/setools/seuser.conf". 3) remake and reload the policy. 4) run restorecon on /usr/bin/seuser and /usr/share/setools/seuser.conf This should make seuser behave properly. I'm not certain what is going on with the outdated fc file - we currently generate that file in our distribution of setools, but had been accidentally included an outdated version with the source. Probably someone just copied that old file (understandably). Hopefully we can get some of these fixes pushed out as an update - is the appropriate process to enter a bugzilla case with a patch? Karl Karl MacMillan Tresys Technology http://www.tresys.com (410)290-1411 ext 134 > ------- previously sent a minute or so ago -- > > You are further along .. > > I get > > [root at hoho2 user1]# date > Mon May 24 13:16:52 CDT 2004 > [root at hoho2 user1]# seuser show users > Could not open policy.conf file > [root at hoho2 user1]# > > I have FC2 installed clean with all updates (incl development) to this > moment (except for ppp - which is having a problem independent of > selinux). > > Booting with kernel boot parame 'selinux=1 enforcing=0' (not enforce=0..) > The boot was done just after a run of '/sbin/fixfiles relabel' at init > level 1. > > BobG > > > On Mon, 24 May 2004 16:13:48 +0100, Anthony Pitt wrote: > >Hi there, > > I hope you can help. I've just installed 'Fedora COre2', with > Selinux > >enabled. > >Using 'seuser' I created a new 'defined' selinux user, with user_r role > >only. I also created the users /home/* directory under the same process. > >I'm using the 'gnome' window manager interface. > >Now when I try to log on with this new user, I get all sorts of errors to > >do with the users environment, eventually allowing me a blank interface, > >with 'right-click' functionality only. > >Any ideas? > >Tony. > > > >---------------------------------------------------------------------- > >A D Pitt Ph:+44(0)1684 895757 > >Rm B006 Woodward Building Fax:+44(0)1684 896660 > >QinetiQ email:t.pitt at eris.qinetiq.com > >Malvern Technology Centre, > >St Andrews Road > >Malvern > >Worcs. > >WR14 3PS > > > >URL:http://www.qinetiq.com/home_enterprise_security.html > >-- > >fedora-selinux-list mailing list > >fedora-selinux-list at redhat.com > >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From kmacmillan at tresys.com Mon May 24 21:34:46 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Mon, 24 May 2004 17:34:46 -0400 Subject: New user In-Reply-To: Message-ID: <200405242134.i4OLYUSf030820@gotham.columbia.tresys.com> > -----Original Message----- > From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list- > bounces at redhat.com] On Behalf Of Anthony Pitt > Sent: Monday, May 24, 2004 11:14 AM > To: fedora-selinux-list at redhat.com > Subject: New user > > Hi there, > I hope you can help. I've just installed 'Fedora COre2', with > Selinux > enabled. > Using 'seuser' I created a new 'defined' selinux user, with user_r role > only. I also created the users /home/* directory under the same process. > I'm using the 'gnome' window manager interface. > Now when I try to log on with this new user, I get all sorts of errors to > do with the users environment, eventually allowing me a blank interface, > with 'right-click' functionality only. > Any ideas? This sounds like your home directory is not labeled correctly, probably as a result of seuser not running properly. See my other message in this thread about how to fix seuser and let me know if that fixes your problems. Karl Karl MacMillan Tresys Technology http://www.tresys.com (410)290-1411 ext 134 > Tony. > > ---------------------------------------------------------------------- > A D Pitt Ph:+44(0)1684 895757 > Rm B006 Woodward Building Fax:+44(0)1684 896660 > QinetiQ email:t.pitt at eris.qinetiq.com > Malvern Technology Centre, > St Andrews Road > Malvern > Worcs. > WR14 3PS > > URL:http://www.qinetiq.com/home_enterprise_security.html > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From bobgus at rcn.com Tue May 25 02:05:14 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Mon, 24 May 2004 21:05:14 -0500 Subject: New user - Not yet In-Reply-To: <200405242133.i4OLX8Sf030813@gotham.columbia.tresys.com> References: Message-ID: I think I followed your instructions, but got the same result as before. Maybe you can see where I went wrong. This is my 'audit tape' [root at hoho2 init.d]# cd /etc/security/selinux/src/policy [root at hoho2 policy]# ls -l | grep drw drwx------ 2 root root 4096 May 22 23:49 appconfig drwx------ 4 root root 4096 May 22 23:49 domains drwxr-xr-x 4 root root 4096 May 22 23:50 file_contexts drwx------ 2 root root 4096 May 22 23:49 flask drwx------ 3 root root 4096 May 22 23:49 macros drwxr-xr-x 2 root root 4096 May 22 23:49 tmp drwx------ 2 root root 4096 May 22 23:49 types [root at hoho2 policy]# cd domains/program [root at hoho2 program]# ls -l total 1460 ,,, -rw------- 1 root root 349 May 11 10:03 screensaver.te -rw------- 1 root root 357 May 11 10:03 screen.te -rw------- 1 root root 3645 May 11 10:03 sendmail.te -rw------- 1 root root 2093 May 11 10:03 setfiles.te -rw------- 1 root root 1630 May 11 10:03 slapd.te ... Not here - as expected. [root at hoho2 program]# [root at hoho2 program]# ls -l unused total 76 -rw------- 1 root root 13362 May 11 10:03 dpkg.te -rw------- 1 root root 1621 May 11 10:03 gatekeeper.te -rw------- 1 root root 7550 May 11 10:03 qmail.te -rw------- 1 root root 5283 May 11 10:03 seuser.te -rw------- 1 root root 1825 May 11 10:03 tinydns.te -rw------- 1 root root 1184 May 11 10:03 uml_net.te -rw------- 1 root root 2021 May 11 10:03 xprint.te Step 1 - mv [root at hoho2 program]# mv unused/seuser.te . [root at hoho2 program]# [root at hoho2 program]# ls -l se* -rw------- 1 root root 3645 May 11 10:03 sendmail.te -rw------- 1 root root 2093 May 11 10:03 setfiles.te -rw------- 1 root root 5283 May 11 10:03 seuser.te Now it is there [root at hoho2 program]# [root at hoho2 program]# cd .. [root at hoho2 domains]# cd .. [root at hoho2 policy]# cd file_contexts [root at hoho2 file_contexts]# ls file_contexts misc program types.fc [root at hoho2 file_contexts]# cd programs bash: cd: programs: No such file or directory [root at hoho2 file_contexts]# cd program [root at hoho2 program]# pwd /etc/security/selinux/src/policy/file_contexts/program [root at hoho2 program]# vim seuser.fc Step 2 - edit [root at hoho2 program]# cat seuser.fc # seuser /usr/bin/seuser system_u:object_r:seuser_exec_t /usr/share/setools/seuser.conf system_u:object_r:seuser_conf_t [root at hoho2 program]# cd /usr/share/setools [root at hoho2 setools]# ls -l seuser* -rw-r--r-- 1 root root 1808 Apr 19 19:50 seuser.conf -rw-r--r-- 1 root root 8980 Apr 19 19:50 seuser_help.txt [root at hoho2 setools]# Step 3 - remake and reload [root at hoho2 program]# cd /etc/security/selinux/src/policy [root at hoho2 policy]# make 2>&1 | tee make.out ... ... > policy.conf.tmp mv policy.conf.tmp policy.conf mkdir -p /etc/security/selinux /usr/bin/checkpolicy -o /etc/security/selinux/policy.17 policy.conf /usr/bin/checkpolicy: loading policy configuration from policy.conf security: 5 users, 7 roles, 1252 types, 1 bools security: 30 classes, 305363 rules /usr/bin/checkpolicy: policy configuration loaded /usr/bin/checkpolicy: writing binary representation (version 17) to /etc/security/selinux/policy.17 Building file_contexts ... install -m 644 file_contexts/file_contexts /etc/security/selinux/file_contexts [root at hoho2 policy]# make reload 2>&1 | tee reload.out /usr/sbin/load_policy /etc/security/selinux/policy.`cat /selinux/policyvers` touch tmp/load [root at hoho2 policy]# [root at hoho2 setools]# cd /etc/security/selinux [root at hoho2 selinux]# ls -l total 29196 -rw-r--r-- 1 root root 87206 May 24 20:12 file_contexts -rw-r--r-- 1 root root 88310 May 11 10:03 file_contexts.rpmnew -rw-r--r-- 1 root root 7383775 May 20 21:37 policy.15.rpmsave -rw-r--r-- 1 root root 7385512 May 20 21:37 policy.16.rpmsave -rw-r--r-- 1 root root 7434273 May 24 20:12 policy.17 -rw-r--r-- 1 root root 7409751 May 11 10:03 policy.17.rpmnew drwx------ 3 root root 4096 May 11 10:03 src [root at hoho2 selinux]# policy.17 seems to have changed as expected Setp 4 - run restorecon [root at hoho2 policy]# /sbin/restorecon -v /usr/bin/seuser /sbin/restorecon set context /usr/bin/seuser->system_u:object_r:seuser_exec_t [root at hoho2 policy]# /sbin/restorecon -v /usr/share/setools/seuser.conf /sbin/restorecon set context /usr/share/setools/seuser.conf->system_u:object_r:seuser_conf_t [root at hoho2 policy]# Step 5 - test [root at hoho2 policy]# which seuser /usr/bin/seuser [root at hoho2 policy]# date Mon May 24 20:26:29 CDT 2004 [root at hoho2 policy]# seuser show users Could not open policy.conf file [root at hoho2 policy]# seuser show Could not open policy.conf file Step 6 - extra information ? [root at hoho2 policy]# [root at hoho2 policy]# ls -l /usr/bin/seuser -rwxr-xr-x 1 root root 106960 Apr 19 19:50 /usr/bin/seuser [root at hoho2 policy]# On Mon, 24 May 2004 17:33:24 -0400, Kerl MacMillan wrote: >> -----Original Message----- >> From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list- >> bounces at redhat.com] On Behalf Of Bob Gustafson >> Sent: Monday, May 24, 2004 2:33 PM >> To: t.pitt at eris.qinetiq.com; Fedora SELinux support list for users & >> developers. >> Subject: Re: New user >> >> Some added information >> >> [root at hoho2 user1]# ls -lZ /etc/security/selinux/src/policy/policy.conf >> -rw-r--r--+ root root >> system_u:object_r:policy_src_t >> /etc/security/selinux/src/policy/policy.conf >> >> [root at hoho2 user1]# cat /proc/version >> Linux version 2.6.6-1.377smp (bhcompile at tweety.build.redhat.com) (gcc >> version 3.3.3 20040412 (Red Hat >> Linux 3.3.3-7)) #1 SMP Sat May 22 15:16:37 EDT 2004 >> >> [root at hoho2 user1]# which seuser >> /usr/bin/seuser >> >> [root at hoho2 user1]# ls -lZ /usr/bin/seuser -rwxr-xr-x+ root root >> system_u:object_r:bin_t >> /usr/bin/seuser >> [root at hoho2 user1]# >> > >This is part of the problem - seuser runs in its own domain so the binary >needs to be labeled seuser_exec_t. Unfortunately it looks like seuser is >quite broken on FC2. You can fix it by: > >1) mv /etc/security/selinux/src/policy/domains/program/unused/seuser.te to >etc/security/selinux/src/policy/domains/program/seuser.te. > >2) edit /etc/security/selinux/src/policy/file_contexts/programs/seuser.fc >changing "/usr/apol/seuser.conf" to "/usr/share/setools/seuser.conf". > >3) remake and reload the policy. > >4) run restorecon on /usr/bin/seuser and /usr/share/setools/seuser.conf > >This should make seuser behave properly. I'm not certain what is going on >with the outdated fc file - we currently generate that file in our >distribution of setools, but had been accidentally included an outdated >version with the source. Probably someone just copied that old file >(understandably). Hopefully we can get some of these fixes pushed out as an >update - is the appropriate process to enter a bugzilla case with a patch? > >Karl > >Karl MacMillan >Tresys Technology >http://www.tresys.com >(410)290-1411 ext 134 > >> ------- previously sent a minute or so ago -- >> >> You are further along .. >> >> I get >> >> [root at hoho2 user1]# date >> Mon May 24 13:16:52 CDT 2004 >> [root at hoho2 user1]# seuser show users >> Could not open policy.conf file >> [root at hoho2 user1]# >> >> I have FC2 installed clean with all updates (incl development) to this >> moment (except for ppp - which is having a problem independent of >> selinux). >> >> Booting with kernel boot parame 'selinux=1 enforcing=0' (not enforce=0..) >> The boot was done just after a run of '/sbin/fixfiles relabel' at init >> level 1. >> >> BobG >> >> >> On Mon, 24 May 2004 16:13:48 +0100, Anthony Pitt wrote: >> >Hi there, >> > I hope you can help. I've just installed 'Fedora COre2', with >> Selinux >> >enabled. >> >Using 'seuser' I created a new 'defined' selinux user, with user_r role >> >only. I also created the users /home/* directory under the same process. >> >I'm using the 'gnome' window manager interface. >> >Now when I try to log on with this new user, I get all sorts of errors to >> >do with the users environment, eventually allowing me a blank interface, >> >with 'right-click' functionality only. >> >Any ideas? >> >Tony. >> > >> >---------------------------------------------------------------------- >> >A D Pitt Ph:+44(0)1684 895757 >> >Rm B006 Woodward Building Fax:+44(0)1684 896660 >> >QinetiQ >email:t.pitt at eris.qinetiq.com >> >Malvern Technology Centre, >> >St Andrews Road >> >Malvern >> >Worcs. >> >WR14 3PS >> > >> >URL:http://www.qinetiq.com/home_enterprise_security.html >> >-- >> >fedora-selinux-list mailing list >> >fedora-selinux-list at redhat.com >> >http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-selinux-list > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list From Valdis.Kletnieks at vt.edu Tue May 25 02:15:15 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 24 May 2004 22:15:15 -0400 Subject: mysql issues... Message-ID: <200405250215.i4P2FFAe027848@turing-police.cc.vt.edu> Running the mysql command as a mortal user dies: $ mysql -hlocalhost -u MMMMMM -p MMMMMM Enter password: ERROR 2002: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (13) after throwing this avc message: May 24 21:34:19 pink kernel: audit(1085448859.069:0): avc: denied { search } for pid=4519 exe=/usr/bin/mysql name=mysql dev=dm-6 ino=129035 scontext=user_u:user_r:user_t tcontext=system_u:object_r:mysqld_db_t tclass=dir It's not able to search /var/lib/mysql to find the socket... A (slightly edited) grep shows us: [/etc/security/selinux/src/policy]3 find . | xargs grep mysqld_var_run | more ./domains/program/apache.te:allow httpd_php_t mysqld_var_run_t:dir { search }; ./domains/program/apache.te:allow httpd_php_t mysqld_var_run_t:sock_file { write }; ./domains/program/mysqld.te:allow mysqld_t mysqld_var_run_t:sock_file create_file_perms; ./domains/program/mysqld.te:allow initrc_t mysqld_var_run_t:sock_file write; ./domains/program/mysqld.te:allow logrotate_t mysqld_var_run_t:dir search; ./domains/program/mysqld.te:allow logrotate_t mysqld_var_run_t:sock_file write; ./file_contexts/program/mysqld.fc:/var/run/mysqld(/.*)? system_u:object_r:mysqld_var_run_t ./file_contexts/file_contexts:/var/run/mysqld(/.*)? system_u:object_r:mysqld_var_run_t Does anybody see a good reason why we don't have this too: mysqld.te: allow mysql_cmd_t mysqld_var_run_t:dir search; mysqld.te: allow mysql_cmd_t mysqld_var_run_t:sock_file write; and add this to mysqld.fc: /usr/bin/mysql system_u:object_r:mysql_cmd_t (or the correct version thereof, it's way too late to think straight.. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From bobgus at rcn.com Tue May 25 02:17:04 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Mon, 24 May 2004 21:17:04 -0500 Subject: Where did apol and awish go? In-Reply-To: <200405242133.i4OLX8Sf030813@gotham.columbia.tresys.com> References: Message-ID: It looks like apol, awish, and libapol did not make it into the latest distribution. apol.tcl uses awish, which is not in the new distribution either [root at hoho2 policy]# find / -name apol\* -print .. /usr/share/doc/setools-1.3/apol_perm_mapping_ver12 /usr/share/doc/setools-1.3/apol_perm_mapping_ver15 /usr/share/doc/setools-1.3/apol_perm_mapping_ver17 /usr/share/doc/setools-1.3/apol_perm_mapping_ver16 /usr/share/doc/setools-1.3/apol_help.txt /usr/share/setools/apol_perm_mapping_ver12 /usr/share/setools/apol_perm_mapping_ver15 /usr/share/setools/apol_perm_mapping /usr/share/setools/apol.tcl /usr/share/setools/apol_perm_mapping_ver17 /usr/share/setools/apol_perm_mapping_ver16 /usr/share/setools/apol_help.txt .. These lines are from the previous FC2(test3-updated) directory /old/usr/local/src/sel/setools-1.3.1/docs-src/apol_help_text.in /old/usr/local/src/sel/setools-1.3.1/apol /old/usr/local/src/sel/setools-1.3.1/apol/apol_perm_mapping_ver12 /old/usr/local/src/sel/setools-1.3.1/apol/apol_gui.c /old/usr/local/src/sel/setools-1.3.1/apol/apol_perm_mapping_ver15 /old/usr/local/src/sel/setools-1.3.1/apol/apol.tcl /old/usr/local/src/sel/setools-1.3.1/apol/apol /old/usr/local/src/sel/setools-1.3.1/apol/apol_perm_mapping_ver17 /old/usr/local/src/sel/setools-1.3.1/apol/apol_perm_mapping_ver16 /old/usr/local/src/sel/setools-1.3.1/apol/apol_gui.o /old/usr/local/src/sel/setools-1.3.1/apol/apol_help.txt /old/usr/local/src/sel/setools-1.3.1/libapol/apol-perm-mapping /old/usr/local/src/sel/setools-1.3.1/libapol/apol_tcl.c /old/usr/local/src/sel/setools-1.3.1/libapol/apolicy_scan.l /old/usr/local/src/sel/setools-1.3.1/libapol/apol_tcl.o /old/usr/local/src/sel/setools-1.3.1/libapol/apol_tcl.h /old/usr/local/src/sel/setools-1.3.1/libapol/apolicy_parse.y [root at hoho2 policy]# [root at hoho2 policy]# find / -name awish -print /old/usr/local/src/sel/setools-1.3.1/awish /old/usr/local/src/sel/setools-1.3.1/awish/awish [root at hoho2 policy]# Bob Gustafson From rhally at mindspring.com Tue May 25 03:22:49 2004 From: rhally at mindspring.com (Richard Hally) Date: Mon, 24 May 2004 23:22:49 -0400 Subject: New user - Not yet In-Reply-To: References: Message-ID: <40B2BC09.6080306@mindspring.com> Bob Gustafson wrote: > I think I followed your instructions, but got the same result as before. > Maybe you can see where I went wrong. > > This is my 'audit tape' > > [root at hoho2 init.d]# cd /etc/security/selinux/src/policy > [root at hoho2 policy]# ls -l | grep drw > drwx------ 2 root root 4096 May 22 23:49 appconfig > drwx------ 4 root root 4096 May 22 23:49 domains > drwxr-xr-x 4 root root 4096 May 22 23:50 file_contexts > drwx------ 2 root root 4096 May 22 23:49 flask > drwx------ 3 root root 4096 May 22 23:49 macros > drwxr-xr-x 2 root root 4096 May 22 23:49 tmp > drwx------ 2 root root 4096 May 22 23:49 types > > [root at hoho2 policy]# cd domains/program > [root at hoho2 program]# ls -l > total 1460 > ,,, > -rw------- 1 root root 349 May 11 10:03 screensaver.te > -rw------- 1 root root 357 May 11 10:03 screen.te > -rw------- 1 root root 3645 May 11 10:03 sendmail.te > -rw------- 1 root root 2093 May 11 10:03 setfiles.te > -rw------- 1 root root 1630 May 11 10:03 slapd.te > ... > > Not here - as expected. > > [root at hoho2 program]# > > [root at hoho2 program]# ls -l unused > total 76 > -rw------- 1 root root 13362 May 11 10:03 dpkg.te > -rw------- 1 root root 1621 May 11 10:03 gatekeeper.te > -rw------- 1 root root 7550 May 11 10:03 qmail.te > -rw------- 1 root root 5283 May 11 10:03 seuser.te > -rw------- 1 root root 1825 May 11 10:03 tinydns.te > -rw------- 1 root root 1184 May 11 10:03 uml_net.te > -rw------- 1 root root 2021 May 11 10:03 xprint.te > > Step 1 - mv > > [root at hoho2 program]# mv unused/seuser.te . > [root at hoho2 program]# > > [root at hoho2 program]# ls -l se* > -rw------- 1 root root 3645 May 11 10:03 sendmail.te > -rw------- 1 root root 2093 May 11 10:03 setfiles.te > -rw------- 1 root root 5283 May 11 10:03 seuser.te > > Now it is there > > [root at hoho2 program]# > > > [root at hoho2 program]# cd .. > [root at hoho2 domains]# cd .. > [root at hoho2 policy]# cd file_contexts > [root at hoho2 file_contexts]# ls > file_contexts misc program types.fc > > [root at hoho2 file_contexts]# cd programs > bash: cd: programs: No such file or directory > > [root at hoho2 file_contexts]# cd program > [root at hoho2 program]# pwd > /etc/security/selinux/src/policy/file_contexts/program > > [root at hoho2 program]# vim seuser.fc > > Step 2 - edit > > [root at hoho2 program]# cat seuser.fc > # seuser > /usr/bin/seuser system_u:object_r:seuser_exec_t > /usr/share/setools/seuser.conf system_u:object_r:seuser_conf_t > > [root at hoho2 program]# cd /usr/share/setools > [root at hoho2 setools]# ls -l seuser* > -rw-r--r-- 1 root root 1808 Apr 19 19:50 seuser.conf > -rw-r--r-- 1 root root 8980 Apr 19 19:50 seuser_help.txt > [root at hoho2 setools]# > > Step 3 - remake and reload > > [root at hoho2 program]# cd /etc/security/selinux/src/policy > > [root at hoho2 policy]# make 2>&1 | tee make.out > ... > ... > > policy.conf.tmp > mv policy.conf.tmp policy.conf > mkdir -p /etc/security/selinux > /usr/bin/checkpolicy -o /etc/security/selinux/policy.17 policy.conf > /usr/bin/checkpolicy: loading policy configuration from policy.conf > security: 5 users, 7 roles, 1252 types, 1 bools > security: 30 classes, 305363 rules > /usr/bin/checkpolicy: policy configuration loaded > /usr/bin/checkpolicy: writing binary representation (version 17) to > /etc/security/selinux/policy.17 > Building file_contexts ... > install -m 644 file_contexts/file_contexts /etc/security/selinux/file_contexts > > > [root at hoho2 policy]# make reload 2>&1 | tee reload.out > /usr/sbin/load_policy /etc/security/selinux/policy.`cat /selinux/policyvers` > touch tmp/load > [root at hoho2 policy]# > > [root at hoho2 setools]# cd /etc/security/selinux > [root at hoho2 selinux]# ls -l > total 29196 > -rw-r--r-- 1 root root 87206 May 24 20:12 file_contexts > -rw-r--r-- 1 root root 88310 May 11 10:03 file_contexts.rpmnew > -rw-r--r-- 1 root root 7383775 May 20 21:37 policy.15.rpmsave > -rw-r--r-- 1 root root 7385512 May 20 21:37 policy.16.rpmsave > -rw-r--r-- 1 root root 7434273 May 24 20:12 policy.17 > -rw-r--r-- 1 root root 7409751 May 11 10:03 policy.17.rpmnew > drwx------ 3 root root 4096 May 11 10:03 src > [root at hoho2 selinux]# > > policy.17 seems to have changed as expected > > Setp 4 - run restorecon > > [root at hoho2 policy]# /sbin/restorecon -v /usr/bin/seuser > /sbin/restorecon set context /usr/bin/seuser->system_u:object_r:seuser_exec_t > > [root at hoho2 policy]# /sbin/restorecon -v /usr/share/setools/seuser.conf > /sbin/restorecon set context > /usr/share/setools/seuser.conf->system_u:object_r:seuser_conf_t > [root at hoho2 policy]# > > Step 5 - test > > [root at hoho2 policy]# which seuser > /usr/bin/seuser > > [root at hoho2 policy]# date > Mon May 24 20:26:29 CDT 2004 > > [root at hoho2 policy]# seuser show users > Could not open policy.conf file > [root at hoho2 policy]# seuser show > Could not open policy.conf file > > Step 6 - extra information ? > > [root at hoho2 policy]# > [root at hoho2 policy]# ls -l /usr/bin/seuser > -rwxr-xr-x 1 root root 106960 Apr 19 19:50 /usr/bin/seuser > [root at hoho2 policy]# > > > On Mon, 24 May 2004 17:33:24 -0400, Kerl MacMillan wrote: > >>>-----Original Message----- >>>From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list- >>>bounces at redhat.com] On Behalf Of Bob Gustafson >>>Sent: Monday, May 24, 2004 2:33 PM >>>To: t.pitt at eris.qinetiq.com; Fedora SELinux support list for users & >>>developers. >>>Subject: Re: New user >>> >>>Some added information >>> >>> [root at hoho2 user1]# ls -lZ /etc/security/selinux/src/policy/policy.conf >>>-rw-r--r--+ root root >>> system_u:object_r:policy_src_t >>>/etc/security/selinux/src/policy/policy.conf >>> >>> [root at hoho2 user1]# cat /proc/version >>> Linux version 2.6.6-1.377smp (bhcompile at tweety.build.redhat.com) (gcc >>>version 3.3.3 20040412 (Red Hat >>> Linux 3.3.3-7)) #1 SMP Sat May 22 15:16:37 EDT 2004 >>> >>> [root at hoho2 user1]# which seuser >>> /usr/bin/seuser >>> >>> [root at hoho2 user1]# ls -lZ /usr/bin/seuser -rwxr-xr-x+ root root >>>system_u:object_r:bin_t >>> /usr/bin/seuser >>> [root at hoho2 user1]# >>> >> >>This is part of the problem - seuser runs in its own domain so the binary >>needs to be labeled seuser_exec_t. Unfortunately it looks like seuser is >>quite broken on FC2. You can fix it by: >> >>1) mv /etc/security/selinux/src/policy/domains/program/unused/seuser.te to >>etc/security/selinux/src/policy/domains/program/seuser.te. >> >>2) edit /etc/security/selinux/src/policy/file_contexts/programs/seuser.fc >>changing "/usr/apol/seuser.conf" to "/usr/share/setools/seuser.conf". >> >>3) remake and reload the policy. >> >>4) run restorecon on /usr/bin/seuser and /usr/share/setools/seuser.conf >> >>This should make seuser behave properly. I'm not certain what is going on >>with the outdated fc file - we currently generate that file in our >>distribution of setools, but had been accidentally included an outdated >>version with the source. Probably someone just copied that old file >>(understandably). Hopefully we can get some of these fixes pushed out as an >>update - is the appropriate process to enter a bugzilla case with a patch? >> >>Karl >> >>Karl MacMillan >>Tresys Technology >>http://www.tresys.com >>(410)290-1411 ext 134 >> >> >>>------- previously sent a minute or so ago -- >>> >>>You are further along .. >>> >>>I get >>> >>> [root at hoho2 user1]# date >>> Mon May 24 13:16:52 CDT 2004 >>> [root at hoho2 user1]# seuser show users >>> Could not open policy.conf file >>> [root at hoho2 user1]# >>> >>>I have FC2 installed clean with all updates (incl development) to this >>>moment (except for ppp - which is having a problem independent of >>>selinux). >>> >>>Booting with kernel boot parame 'selinux=1 enforcing=0' (not enforce=0..) >>>The boot was done just after a run of '/sbin/fixfiles relabel' at init >>>level 1. >>> >>>BobG >>> >>> >>>On Mon, 24 May 2004 16:13:48 +0100, Anthony Pitt wrote: >>> >>>>Hi there, >>>> I hope you can help. I've just installed 'Fedora COre2', with >>> >>>Selinux >>> >>>>enabled. >>>>Using 'seuser' I created a new 'defined' selinux user, with user_r role >>>>only. I also created the users /home/* directory under the same process. >>>>I'm using the 'gnome' window manager interface. >>>>Now when I try to log on with this new user, I get all sorts of errors to >>>>do with the users environment, eventually allowing me a blank interface, >>>>with 'right-click' functionality only. >>>>Any ideas? >>>>Tony. >>>> >>>>---------------------------------------------------------------------- >>>>A D Pitt Ph:+44(0)1684 895757 >>>>Rm B006 Woodward Building Fax:+44(0)1684 896660 >>>>QinetiQ >> >>email:t.pitt at eris.qinetiq.com >> >>>>Malvern Technology Centre, >>>>St Andrews Road >>>>Malvern >>>>Worcs. >>>>WR14 3PS >>>> >>>>URL:http://www.qinetiq.com/home_enterprise_security.html >>>>-- >>>>fedora-selinux-list mailing list >>>>fedora-selinux-list at redhat.com >>>>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> >>>-- >>>fedora-selinux-list mailing list >>>fedora-selinux-list at redhat.com >>>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >>-- >>fedora-selinux-list mailing list >>fedora-selinux-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > I found one more step to be done. You need to edit /usr/share/setools/seuser.conf and change the line for policy.conf to /etc/security/selinux/src/policy/policy.conf i.e adding the /policy/ after src HTH Richard Hally From bobgus at rcn.com Tue May 25 06:05:41 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Tue, 25 May 2004 01:05:41 -0500 Subject: New user - Not yet - OK cool In-Reply-To: <40B2BC09.6080306@mindspring.com> References: Message-ID: Richard Hally wrote: >Bob Gustafson wrote: > >> I think I followed your instructions, but got the same result as before. >> Maybe you can see where I went wrong. >> >> This is my 'audit tape' >> >> [root at hoho2 init.d]# cd /etc/security/selinux/src/policy >> [root at hoho2 policy]# ls -l | grep drw >> drwx------ 2 root root 4096 May 22 23:49 appconfig >> drwx------ 4 root root 4096 May 22 23:49 domains >> drwxr-xr-x 4 root root 4096 May 22 23:50 file_contexts >> drwx------ 2 root root 4096 May 22 23:49 flask >> drwx------ 3 root root 4096 May 22 23:49 macros >> drwxr-xr-x 2 root root 4096 May 22 23:49 tmp >> drwx------ 2 root root 4096 May 22 23:49 types >> >> [root at hoho2 policy]# cd domains/program >> [root at hoho2 program]# ls -l >> total 1460 >> ,,, >> -rw------- 1 root root 349 May 11 10:03 screensaver.te >> -rw------- 1 root root 357 May 11 10:03 screen.te >> -rw------- 1 root root 3645 May 11 10:03 sendmail.te >> -rw------- 1 root root 2093 May 11 10:03 setfiles.te >> -rw------- 1 root root 1630 May 11 10:03 slapd.te >> ... >> >> Not here - as expected. >> >> [root at hoho2 program]# >> >> [root at hoho2 program]# ls -l unused >> total 76 >> -rw------- 1 root root 13362 May 11 10:03 dpkg.te >> -rw------- 1 root root 1621 May 11 10:03 gatekeeper.te >> -rw------- 1 root root 7550 May 11 10:03 qmail.te >> -rw------- 1 root root 5283 May 11 10:03 seuser.te >> -rw------- 1 root root 1825 May 11 10:03 tinydns.te >> -rw------- 1 root root 1184 May 11 10:03 uml_net.te >> -rw------- 1 root root 2021 May 11 10:03 xprint.te >> >> Step 1 - mv >> >> [root at hoho2 program]# mv unused/seuser.te . >> [root at hoho2 program]# >> >> [root at hoho2 program]# ls -l se* >> -rw------- 1 root root 3645 May 11 10:03 sendmail.te >> -rw------- 1 root root 2093 May 11 10:03 setfiles.te >> -rw------- 1 root root 5283 May 11 10:03 seuser.te >> >> Now it is there >> >> [root at hoho2 program]# >> >> >> [root at hoho2 program]# cd .. >> [root at hoho2 domains]# cd .. >> [root at hoho2 policy]# cd file_contexts >> [root at hoho2 file_contexts]# ls >> file_contexts misc program types.fc >> >> [root at hoho2 file_contexts]# cd programs >> bash: cd: programs: No such file or directory >> >> [root at hoho2 file_contexts]# cd program >> [root at hoho2 program]# pwd >> /etc/security/selinux/src/policy/file_contexts/program >> >> [root at hoho2 program]# vim seuser.fc >> >> Step 2 - edit >> >> [root at hoho2 program]# cat seuser.fc >> # seuser >> /usr/bin/seuser system_u:object_r:seuser_exec_t >> /usr/share/setools/seuser.conf system_u:object_r:seuser_conf_t >> >> [root at hoho2 program]# cd /usr/share/setools >> [root at hoho2 setools]# ls -l seuser* >> -rw-r--r-- 1 root root 1808 Apr 19 19:50 seuser.conf >> -rw-r--r-- 1 root root 8980 Apr 19 19:50 seuser_help.txt >> [root at hoho2 setools]# >> >> Step 3 - remake and reload >> >> [root at hoho2 program]# cd /etc/security/selinux/src/policy >> >> [root at hoho2 policy]# make 2>&1 | tee make.out >> ... >> ... >> > policy.conf.tmp >> mv policy.conf.tmp policy.conf >> mkdir -p /etc/security/selinux >> /usr/bin/checkpolicy -o /etc/security/selinux/policy.17 policy.conf >> /usr/bin/checkpolicy: loading policy configuration from policy.conf >> security: 5 users, 7 roles, 1252 types, 1 bools >> security: 30 classes, 305363 rules >> /usr/bin/checkpolicy: policy configuration loaded >> /usr/bin/checkpolicy: writing binary representation (version 17) to >> /etc/security/selinux/policy.17 >> Building file_contexts ... >> install -m 644 file_contexts/file_contexts >>/etc/security/selinux/file_contexts >> >> >> [root at hoho2 policy]# make reload 2>&1 | tee reload.out >> /usr/sbin/load_policy /etc/security/selinux/policy.`cat /selinux/policyvers` >> touch tmp/load >> [root at hoho2 policy]# >> >> [root at hoho2 setools]# cd /etc/security/selinux >> [root at hoho2 selinux]# ls -l >> total 29196 >> -rw-r--r-- 1 root root 87206 May 24 20:12 file_contexts >> -rw-r--r-- 1 root root 88310 May 11 10:03 file_contexts.rpmnew >> -rw-r--r-- 1 root root 7383775 May 20 21:37 policy.15.rpmsave >> -rw-r--r-- 1 root root 7385512 May 20 21:37 policy.16.rpmsave >> -rw-r--r-- 1 root root 7434273 May 24 20:12 policy.17 >> -rw-r--r-- 1 root root 7409751 May 11 10:03 policy.17.rpmnew >> drwx------ 3 root root 4096 May 11 10:03 src >> [root at hoho2 selinux]# >> >> policy.17 seems to have changed as expected >> >> Setp 4 - run restorecon >> >> [root at hoho2 policy]# /sbin/restorecon -v /usr/bin/seuser >> /sbin/restorecon set context >>/usr/bin/seuser->system_u:object_r:seuser_exec_t >> >> [root at hoho2 policy]# /sbin/restorecon -v /usr/share/setools/seuser.conf >> /sbin/restorecon set context >> /usr/share/setools/seuser.conf->system_u:object_r:seuser_conf_t >> [root at hoho2 policy]# >> >> Step 5 - test >> >> [root at hoho2 policy]# which seuser >> /usr/bin/seuser >> >> [root at hoho2 policy]# date >> Mon May 24 20:26:29 CDT 2004 >> >> [root at hoho2 policy]# seuser show users >> Could not open policy.conf file >> [root at hoho2 policy]# seuser show >> Could not open policy.conf file >> >> Step 6 - extra information ? >> >> [root at hoho2 policy]# >> [root at hoho2 policy]# ls -l /usr/bin/seuser >> -rwxr-xr-x 1 root root 106960 Apr 19 19:50 /usr/bin/seuser >> [root at hoho2 policy]# >> >> >> On Mon, 24 May 2004 17:33:24 -0400, Kerl MacMillan wrote: >> >>>>-----Original Message----- >>>>From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list- >>>>bounces at redhat.com] On Behalf Of Bob Gustafson >>>>Sent: Monday, May 24, 2004 2:33 PM >>>>To: t.pitt at eris.qinetiq.com; Fedora SELinux support list for users & >>>>developers. >>>>Subject: Re: New user >>>> >>>>Some added information >>>> >>>> [root at hoho2 user1]# ls -lZ /etc/security/selinux/src/policy/policy.conf >>>>-rw-r--r--+ root root >>>> system_u:object_r:policy_src_t >>>>/etc/security/selinux/src/policy/policy.conf >>>> >>>> [root at hoho2 user1]# cat /proc/version >>>> Linux version 2.6.6-1.377smp (bhcompile at tweety.build.redhat.com) (gcc >>>>version 3.3.3 20040412 (Red Hat >>>> Linux 3.3.3-7)) #1 SMP Sat May 22 15:16:37 EDT 2004 >>>> >>>> [root at hoho2 user1]# which seuser >>>> /usr/bin/seuser >>>> >>>> [root at hoho2 user1]# ls -lZ /usr/bin/seuser -rwxr-xr-x+ root root >>>>system_u:object_r:bin_t >>>> /usr/bin/seuser >>>> [root at hoho2 user1]# >>>> >>> >>>This is part of the problem - seuser runs in its own domain so the binary >>>needs to be labeled seuser_exec_t. Unfortunately it looks like seuser is >>>quite broken on FC2. You can fix it by: >>> >>>1) mv /etc/security/selinux/src/policy/domains/program/unused/seuser.te to >>>etc/security/selinux/src/policy/domains/program/seuser.te. >>> >>>2) edit /etc/security/selinux/src/policy/file_contexts/programs/seuser.fc >>>changing "/usr/apol/seuser.conf" to "/usr/share/setools/seuser.conf". >>> >>>3) remake and reload the policy. >>> >>>4) run restorecon on /usr/bin/seuser and /usr/share/setools/seuser.conf >>> >>>This should make seuser behave properly. I'm not certain what is going on >>>with the outdated fc file - we currently generate that file in our >>>distribution of setools, but had been accidentally included an outdated >>>version with the source. Probably someone just copied that old file >>>(understandably). Hopefully we can get some of these fixes pushed out as an >>>update - is the appropriate process to enter a bugzilla case with a patch? >>> >>>Karl >>> >>>Karl MacMillan >>>Tresys Technology >>>http://www.tresys.com >>>(410)290-1411 ext 134 >>> >>> >>>>------- previously sent a minute or so ago -- >>>> >>>>You are further along .. >>>> >>>>I get >>>> >>>> [root at hoho2 user1]# date >>>> Mon May 24 13:16:52 CDT 2004 >>>> [root at hoho2 user1]# seuser show users >>>> Could not open policy.conf file >>>> [root at hoho2 user1]# >>>> >>>>I have FC2 installed clean with all updates (incl development) to this >>>>moment (except for ppp - which is having a problem independent of >>>>selinux). >>>> >>>>Booting with kernel boot parame 'selinux=1 enforcing=0' (not enforce=0..) >>>>The boot was done just after a run of '/sbin/fixfiles relabel' at init >>>>level 1. >>>> >>>>BobG >>>> >>>> >>>>On Mon, 24 May 2004 16:13:48 +0100, Anthony Pitt wrote: >>>> >>>>>Hi there, >>>>> I hope you can help. I've just installed 'Fedora COre2', with >>>> >>>>Selinux >>>> >>>>>enabled. >>>>>Using 'seuser' I created a new 'defined' selinux user, with user_r role >>>>>only. I also created the users /home/* directory under the same process. >>>>>I'm using the 'gnome' window manager interface. >>>>>Now when I try to log on with this new user, I get all sorts of errors to >>>>>do with the users environment, eventually allowing me a blank interface, >>>>>with 'right-click' functionality only. >>>>>Any ideas? >>>>>Tony. >>>>> >>>>>---------------------------------------------------------------------- >>>>>A D Pitt Ph:+44(0)1684 895757 >>>>>Rm B006 Woodward Building Fax:+44(0)1684 896660 >>>>>QinetiQ >>> >>>email:t.pitt at eris.qinetiq.com >>> >>>>>Malvern Technology Centre, >>>>>St Andrews Road >>>>>Malvern >>>>>Worcs. >>>>>WR14 3PS >>>>> >>>>>URL:http://www.qinetiq.com/home_enterprise_security.html >>>>>-- >>>>>fedora-selinux-list mailing list >>>>>fedora-selinux-list at redhat.com >>>>>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>> >>>>-- >>>>fedora-selinux-list mailing list >>>>fedora-selinux-list at redhat.com >>>>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> >>>-- >>>fedora-selinux-list mailing list >>>fedora-selinux-list at redhat.com >>>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >I found one more step to be done. You need to edit >/usr/share/setools/seuser.conf and change the line for policy.conf to >/etc/security/selinux/src/policy/policy.conf > >i.e adding the /policy/ after src >HTH >Richard Hally > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list OK, cool - that did it. (wasn't this an old bug?) [root at hoho2 setools]# vim seuser.conf [root at hoho2 setools]# date Tue May 25 00:58:56 CDT 2004 [root at hoho2 setools]# seuser show users system_u: system_r user_u: user_r sysadm_r system_r root: staff_r sysadm_r system_r cyrus: cyrus_r mailman: mailman_r [root at hoho2 setools]# From rhally at mindspring.com Tue May 25 06:54:03 2004 From: rhally at mindspring.com (Richard Hally) Date: Tue, 25 May 2004 02:54:03 -0400 Subject: New user - Not yet - OK cool In-Reply-To: References: Message-ID: <40B2ED8B.8060907@mindspring.com> Bob Gustafson wrote: > Richard Hally wrote: >>I found one more step to be done. You need to edit >>/usr/share/setools/seuser.conf and change the line for policy.conf to >>/etc/security/selinux/src/policy/policy.conf >> >>i.e adding the /policy/ after src >>HTH >>Richard Hally >> >>-- >>fedora-selinux-list mailing list >>fedora-selinux-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > OK, cool - that did it. (wasn't this an old bug?) > I was also thinking it was an old bug. It may be that the FC2 final contained setools-1.3-2 and we had seen the fix in setools-1.3.1-?. Richard Hally From selinux at comcast.net Mon May 24 22:35:38 2004 From: selinux at comcast.net (Tom London) Date: Mon, 24 May 2004 15:35:38 -0700 Subject: firstbook new user creation? Message-ID: <40B278BA.8000307@comcast.net> yeah. firstboot appears to not be labeling home directory and files correctly. (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123856) Work around: boot single user run 'fixfiles relabel' boot up multiuser You should then be able to login as usual. ------------------------------------------------------------------------ * /From/: billy ball * /To/: fedora-selinux-list redhat com * /Subject/: firstbook new user creation? * /Date/: Mon, 24 May 2004 15:26:33 -0400 (EDT) ------------------------------------------------------------------------ hi! cool distro! installed FC2 onto a dual-CPU P4 MPC box w/1GB RAM, 80GB SATA drive, DVD/CDRW drive... installed w/no problems (using selinux, enforced selection during install)... however, creating a new user using firstboot dialog doesn't work... my workaround was root login via Ctrl+Alt+F2, then role selection... known problem? From matthew.east at iue.it Tue May 25 10:44:16 2004 From: matthew.east at iue.it (Matthew East) Date: Tue, 25 May 2004 12:44:16 +0200 Subject: OpenOffice.org fails to start Message-ID: <1085481856.1879.9.camel@localhost> This is a strange problem. I have recently enabled selinux on my system and now I cannot start OpenOffice.org. Everything else is working fine. When I start it it doesn't even get to the splash screen. I have NO MESSAGES in dmesg or /var/log/messages about this (how can this be??!??!!), and yet if I set selinux to permissive it loads fine. Can anyone help me with this?? While I'm here, can somebody give me the solution to this error message (which seems not to cause any problems), which occurs when I do a "su" in Gnome Terminal. audit(1085481816.902:0): avc: denied { add_name } for pid=1981 exe=/bin/su name=.xauthdgXnvH scontext=user_u:user_r:user_su_t tcontext=root:object_r:staff_home_dir_t tclass=dir thanks everyone. Matt From kmacmillan at tresys.com Tue May 25 13:10:02 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Tue, 25 May 2004 09:10:02 -0400 Subject: New user - Not yet - OK cool In-Reply-To: Message-ID: <200405251309.i4PD9jSf032697@gotham.columbia.tresys.com> Karl MacMillan Tresys Technology http://www.tresys.com (410)290-1411 ext 134 [snip] > >I found one more step to be done. You need to edit > >/usr/share/setools/seuser.conf and change the line for policy.conf to > >/etc/security/selinux/src/policy/policy.conf > > > >i.e adding the /policy/ after src > >HTH > >Richard Hally > > > >-- > >fedora-selinux-list mailing list > >fedora-selinux-list at redhat.com > >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > OK, cool - that did it. (wasn't this an old bug?) > Yes it was - what version of the setools package do you have? Karl > [root at hoho2 setools]# vim seuser.conf > [root at hoho2 setools]# date > Tue May 25 00:58:56 CDT 2004 > [root at hoho2 setools]# seuser show users > > system_u: system_r > user_u: user_r sysadm_r system_r > root: staff_r sysadm_r system_r > cyrus: cyrus_r > mailman: mailman_r > > > [root at hoho2 setools]# > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From bobgus at rcn.com Tue May 25 14:27:47 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Tue, 25 May 2004 09:27:47 -0500 Subject: New user - Not yet - OK cool In-Reply-To: <200405251309.i4PD9jSf032697@gotham.columbia.tresys.com> References: Message-ID: >Karl MacMillan >Tresys Technology >http://www.tresys.com >(410)290-1411 ext 134 > >[snip] > >> >I found one more step to be done. You need to edit >> >/usr/share/setools/seuser.conf and change the line for policy.conf to >> >/etc/security/selinux/src/policy/policy.conf >> > >> >i.e adding the /policy/ after src >> >HTH >> >Richard Hally >> > >> >-- snip >> >> >> OK, cool - that did it. (wasn't this an old bug?) >> > >Yes it was - what version of the setools package do you have? > >Karl [user1 at hoho2 user1]$ rpm -q setools setools-1.3-2 [user1 at hoho2 user1]$ snip From bobgus at rcn.com Tue May 25 14:59:04 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Tue, 25 May 2004 09:59:04 -0500 Subject: OpenOffice.org fails to start In-Reply-To: <1085481856.1879.9.camel@localhost> Message-ID: On Tue, 25 May 2004 12:44:16 +0200, Matthew East wrote: >This is a strange problem. I have recently enabled selinux on my system >and now I cannot start OpenOffice.org. Everything else is working fine. >When I start it it doesn't even get to the splash screen. I have NO >MESSAGES in dmesg or /var/log/messages about this (how can this >be??!??!!), and yet if I set selinux to permissive it loads fine. > >Can anyone help me with this?? It works for me. I was running with enforcing off (setenforce 0) until now - I was able to open oo.write both with it off and again with (setenforce 1). I do get a blizzard of 'denied' messages in /var/log/messages which is a bit puzzling. I can attach these if desired. BobG > >While I'm here, can somebody give me the solution to this error message >(which seems not to cause any problems), which occurs when I do a "su" >in Gnome Terminal. > >audit(1085481816.902:0): avc: denied { add_name } for pid=1981 >exe=/bin/su name=.xauthdgXnvH scontext=user_u:user_r:user_su_t >tcontext=root:object_r:staff_home_dir_t tclass=dir > >thanks everyone. > >Matt > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Tue May 25 18:47:11 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 25 May 2004 14:47:11 -0400 Subject: New design for policy on disk allowing multiple policy rpms to be simultaniously installed. Message-ID: <40B394AF.2000801@redhat.com> As I have been trying to build a new policy we kept on coming up with problems in replacing the current policy file with either strict or targeted policy. In the next version of Fedora Core we will be shipping a targeted policy on the iso images. We will continue to make the strict policy available separately. The problem comes in that these policy files conflict and we continued to work on how we could allow them both to be installed and have the user fairly easily switch between policies. With this new design, I could envision other policies being added in the future and test machines able to switch between the policies. 1. We are breaking the policy file out into two separate policy packages selinux-policy-strict (-source also) - Containing pretty much the current policy selinux-policy-targeted (-source also) - Containing a policy where most processed run in unconfined_t and only specific services run under a different security context. 2. Both packages obsolete the current policy rpm. 3. We want both policy files to be installable and not conflict with each other. 4. Policy files will be installed in the /etc/selinux/(strict|targeted) directory. Under this tree there will be at least three additional directiories policy/ Containing the compiled policy file contexts/ Containing all the contexts files file_contexts, default_contexts, default_type users/ Containing user specific default context files. root in particular. src/ Containing the policy src directory. 5. Tools and libraries (fixfiles, libselinux, init, and setools) will be modified to use the /etc/sysconfig/selinux file to determine which policy to currently use on the system and where the policy files are located. 6. If during the install /etc/sysconfig/selinux does not exist or does not contain an entry for the type of policy, the first one installed will set the context to itself. cat /etc/sysconfig/selinux # # Change the following line to enforcing, permissive or disabled. # On the next boot the machine will come up in one the selected mode # SELINUX=enforcing # # Select the type of policy that you are running current values are # strict and targeted # SELINUXTYPE=strict So if nothing is in the /etc/sysconfig/selinux file and you install strict, strict will be added to config file. If there is an entry then it will be left there. This will allow the installation of both the Strict and Targeted policy and the user can change the choice via this file and can then relabel 7. We will not use symbolic links. Use of symbolic links complicates policy and requires a user to modify them if he wanted to change the security context that he wants to run as. Also you end up with conflicts in the post install scripts which need to replace the old symbolic link with a new one. Comments? Dan From n3npq at nc.rr.com Tue May 25 19:18:33 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 25 May 2004 15:18:33 -0400 Subject: New design for policy on disk allowing multiple policy rpms to be simultaniously installed. In-Reply-To: <40B394AF.2000801@redhat.com> References: <40B394AF.2000801@redhat.com> Message-ID: <40B39C09.5040300@nc.rr.com> Daniel J Walsh wrote: > As I have been trying to build a new policy we kept on coming up with > problems in replacing the current policy file with either strict or > targeted policy. In the next version of Fedora Core we will be > shipping a targeted policy on the iso images. We will continue to > make the strict policy available separately. The problem comes in > that these policy files conflict and we continued to work on how we > could allow them both to be installed and have the user fairly easily > switch between policies. With this new design, I could envision other > policies being added in the future and test machines able to switch > between the policies. > > 1. We are breaking the policy file out into two separate policy packages > > selinux-policy-strict (-source also) > - Containing pretty much the current policy > selinux-policy-targeted (-source also) > - Containing a policy where most processed run in unconfined_t > and only specific services run under a different security context. > > 2. Both packages obsolete the current policy rpm. > > 3. We want both policy files to be installable and not conflict with > each other. Hmmm, how is rpm to find out which file_contexts is to be used? Or is targeted policy a strict ;-) subset of strict policy? > > 4. Policy files will be installed in the > /etc/selinux/(strict|targeted) directory. > Under this tree there will be at least three additional directiories > > policy/ > Containing the compiled policy file > > contexts/ > Containing all the contexts files > file_contexts, default_contexts, default_type > users/ > Containing user specific default context files. root in > particular. > > src/ > Containing the policy src directory. > > 5. Tools and libraries (fixfiles, libselinux, init, and setools) will > be modified to use the /etc/sysconfig/selinux file to determine which > policy to currently use on the system and where the policy files are > located. > > 6. If during the install /etc/sysconfig/selinux does not exist or does > not contain an entry for the type of policy, the first one installed > will set the context to itself. How much legacy compatibility is desired? I sure hope you say "None." ;-) > > cat /etc/sysconfig/selinux > # > # Change the following line to enforcing, permissive or disabled. > # On the next boot the machine will come up in one the selected mode > # > SELINUX=enforcing > # > # Select the type of policy that you are running current values are > # strict and targeted > # > SELINUXTYPE=strict > > > So if nothing is in the /etc/sysconfig/selinux file and you install > strict, strict will be added > to config file. If there is an entry then it will be left there. > This will allow the installation of both the Strict and Targeted > policy and the user can change the choice via this file and can then > relabel > > 7. We will not use symbolic links. Use of symbolic links complicates > policy and requires a user to modify them if he wanted to change the > security context that he wants to run as. Also you end up with > conflicts in the post install scripts which need to replace the old > symbolic link with a new one. Well, the existing means to handle simultaneous installs of otherwise mutually exclusive packages is the alternatives mechanism used to handle sendmail vs. postfix and lpd vs. cups. Yes, symlinks, feeble, but that is the existing mechanism, might as well use if in the distro. 73 de Jeff From n3npq at nc.rr.com Tue May 25 19:29:58 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 25 May 2004 15:29:58 -0400 Subject: New design for policy on disk allowing multiple policy rpms to be simultaniously installed. In-Reply-To: <40B394AF.2000801@redhat.com> References: <40B394AF.2000801@redhat.com> Message-ID: <40B39EB6.3060503@nc.rr.com> Daniel J Walsh wrote: > > > 6. If during the install /etc/sysconfig/selinux does not exist or does > not contain an entry for the type of policy, the first one installed > will set the context to itself. > > cat /etc/sysconfig/selinux > # > # Change the following line to enforcing, permissive or disabled. > # On the next boot the machine will come up in one the selected mode > # > SELINUX=enforcing > # > # Select the type of policy that you are running current values are > # strict and targeted > # > SELINUXTYPE=strict > > > So if nothing is in the /etc/sysconfig/selinux file and you install > strict, strict will be added > to config file. If there is an entry then it will be left there. > This will allow the installation of both the Strict and Targeted > policy and the user can change the choice via this file and can then > relabel Ah, you want Yet Another Config File parser added to all applications that need to determine which policy is going to be installed. Well, that's doable, but, well, ick. Perhaps there is a new routine in libselinux to simplify which policy obtains. There are run-time issues as well: What if you are upgrading from targeted to strict, which regexes should be used during upgrade? 73 de Jeff From notting at redhat.com Tue May 25 19:37:58 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 25 May 2004 15:37:58 -0400 Subject: New design for policy on disk allowing multiple policy rpms to be simultaniously installed. In-Reply-To: <40B394AF.2000801@redhat.com> References: <40B394AF.2000801@redhat.com> Message-ID: <20040525193758.GE8072@nostromo.devel.redhat.com> Daniel J Walsh (dwalsh at redhat.com) said: > 5. Tools and libraries (fixfiles, libselinux, init, and setools) will be > modified to use the /etc/sysconfig/selinux file to determine which > policy to currently use on the system and where the policy files are > located. > > 6. If during the install /etc/sysconfig/selinux does not exist or does > not contain an entry for the type of policy, the first one installed > will set the context to itself. > > cat /etc/sysconfig/selinux > # > # Change the following line to enforcing, permissive or disabled. > # On the next boot the machine will come up in one the selected mode > # > SELINUX=enforcing > # > # Select the type of policy that you are running current values are > # strict and targeted > # > SELINUXTYPE=strict This requires rewriting the config tool to handle this (and not blow it away each time it's run... currently it will.) Bill From dwalsh at redhat.com Tue May 25 19:34:34 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 25 May 2004 15:34:34 -0400 Subject: New design for policy on disk allowing multiple policy rpms to be simultaniously installed. In-Reply-To: <40B39C09.5040300@nc.rr.com> References: <40B394AF.2000801@redhat.com> <40B39C09.5040300@nc.rr.com> Message-ID: <40B39FCA.10806@redhat.com> Jeff Johnson wrote: > Daniel J Walsh wrote: > >> As I have been trying to build a new policy we kept on coming up with >> problems in replacing the current policy file with either strict or >> targeted policy. In the next version of Fedora Core we will be >> shipping a targeted policy on the iso images. We will continue to >> make the strict policy available separately. The problem comes in >> that these policy files conflict and we continued to work on how we >> could allow them both to be installed and have the user fairly >> easily switch between policies. With this new design, I could >> envision other policies being added in the future and test machines >> able to switch between the policies. >> >> 1. We are breaking the policy file out into two separate policy packages >> >> selinux-policy-strict (-source also) >> - Containing pretty much the current policy >> selinux-policy-targeted (-source also) >> - Containing a policy where most processed run in unconfined_t >> and only specific services run under a different security context. > > >> >> 2. Both packages obsolete the current policy rpm. >> >> 3. We want both policy files to be installable and not conflict with >> each other. > > > > Hmmm, how is rpm to find out which file_contexts is to be used? Or is > targeted policy a strict ;-) subset > of strict policy? libselinux is converted to use the correct one. selinux_policypath is set the the dirctory where the policy is installed during library initialization. So files contexts would be in ${selinux_policypath}/contexts/file_contexts please excuse the pseudo code. > >> >> 4. Policy files will be installed in the >> /etc/selinux/(strict|targeted) directory. >> Under this tree there will be at least three additional directiories >> >> policy/ >> Containing the compiled policy file >> >> contexts/ >> Containing all the contexts files >> file_contexts, default_contexts, default_type >> users/ >> Containing user specific default context files. root in >> particular. >> >> src/ >> Containing the policy src directory. >> >> 5. Tools and libraries (fixfiles, libselinux, init, and setools) will >> be modified to use the /etc/sysconfig/selinux file to determine which >> policy to currently use on the system and where the policy files are >> located. >> >> 6. If during the install /etc/sysconfig/selinux does not exist or >> does not contain an entry for the type of policy, the first one >> installed will set the context to itself. > > > > How much legacy compatibility is desired? I sure hope you say "None." ;-) We are looking for a clean break. Since we have a small installed base, this should be possible. :^) > >> >> cat /etc/sysconfig/selinux >> # >> # Change the following line to enforcing, permissive or disabled. >> # On the next boot the machine will come up in one the selected mode >> # >> SELINUX=enforcing >> # >> # Select the type of policy that you are running current values are >> # strict and targeted >> # >> SELINUXTYPE=strict >> >> >> So if nothing is in the /etc/sysconfig/selinux file and you install >> strict, strict will be added >> to config file. If there is an entry then it will be left there. >> This will allow the installation of both the Strict and Targeted >> policy and the user can change the choice via this file and can then >> relabel >> >> 7. We will not use symbolic links. Use of symbolic links complicates >> policy and requires a user to modify them if he wanted to change the >> security context that he wants to run as. Also you end up with >> conflicts in the post install scripts which need to replace the old >> symbolic link with a new one. > > > > Well, the existing means to handle simultaneous installs of otherwise > mutually exclusive packages is the > alternatives mechanism used to handle sendmail vs. postfix and lpd vs. > cups. > > Yes, symlinks, feeble, but that is the existing mechanism, might as > well use if in the distro. > > 73 de Jeff > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Tue May 25 19:36:45 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 25 May 2004 15:36:45 -0400 Subject: New design for policy on disk allowing multiple policy rpms to be simultaniously installed. In-Reply-To: <40B39EB6.3060503@nc.rr.com> References: <40B394AF.2000801@redhat.com> <40B39EB6.3060503@nc.rr.com> Message-ID: <40B3A04D.8080500@redhat.com> Jeff Johnson wrote: > Daniel J Walsh wrote: > >> >> >> 6. If during the install /etc/sysconfig/selinux does not exist or >> does not contain an entry for the type of policy, the first one >> installed will set the context to itself. >> >> cat /etc/sysconfig/selinux >> # >> # Change the following line to enforcing, permissive or disabled. >> # On the next boot the machine will come up in one the selected mode >> # >> SELINUX=enforcing >> # >> # Select the type of policy that you are running current values are >> # strict and targeted >> # >> SELINUXTYPE=strict >> >> >> So if nothing is in the /etc/sysconfig/selinux file and you install >> strict, strict will be added >> to config file. If there is an entry then it will be left there. >> This will allow the installation of both the Strict and Targeted >> policy and the user can change the choice via this file and can then >> relabel > > > > Ah, you want Yet Another Config File parser added to all applications > that need to determine which policy > is going to be installed. Well, that's doable, but, well, ick. Perhaps > there is a new routine in libselinux to > simplify which policy obtains. There are run-time issues as well: What > if you are upgrading from targeted > to strict, which regexes should be used during upgrade? > Well no, the libselinux should handle most of the parsing. New functions are being added to return you the proper file. From a script it is a simple as . /etc/sysconfig/selinux echo $SELINUXTYPE > 73 de Jeff > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From russell at coker.com.au Wed May 26 04:17:40 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 26 May 2004 14:17:40 +1000 Subject: mysql issues... In-Reply-To: <200405250215.i4P2FFAe027848@turing-police.cc.vt.edu> References: <200405250215.i4P2FFAe027848@turing-police.cc.vt.edu> Message-ID: <200405261417.40958.russell@coker.com.au> On Tue, 25 May 2004 12:15, Valdis.Kletnieks at vt.edu wrote: > Running the mysql command as a mortal user dies: > > $ mysql -hlocalhost -u MMMMMM -p MMMMMM > Enter password: > ERROR 2002: Can't connect to local MySQL server through socket > '/var/lib/mysql/mysql.sock' (13) > > after throwing this avc message: > May 24 21:34:19 pink kernel: audit(1085448859.069:0): avc: denied { > search } for pid=4519 exe=/usr/bin/mysql name=mysql dev=dm-6 ino=129035 > scontext=user_u:user_r:user_t tcontext=system_u:object_r:mysqld_db_t > tclass=dir How should we determine who gets mysql client access? Should we have a tunable determining whether we allow userdomain? > It's not able to search /var/lib/mysql to find the socket... > > A (slightly edited) grep shows us: > > Does anybody see a good reason why we don't have this too: > > mysqld.te: allow mysql_cmd_t mysqld_var_run_t:dir search; > mysqld.te: allow mysql_cmd_t mysqld_var_run_t:sock_file write; > > and add this to mysqld.fc: > > /usr/bin/mysql system_u:object_r:mysql_cmd_t Why have mysql_cmd_t instead of just allowing user_t directly? What is the benefit in having a domain for client access? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From fedora at andrewfarris.com Wed May 26 05:15:56 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Tue, 25 May 2004 22:15:56 -0700 Subject: New design for policy on disk allowing multiple policy rpms to be simultaniously installed. In-Reply-To: <40B394AF.2000801@redhat.com> References: <40B394AF.2000801@redhat.com> Message-ID: <1085548556.11149.20.camel@CirithUngol> On Tue, 2004-05-25 at 14:47 -0400, Daniel J Walsh wrote: > 1. We are breaking the policy file out into two separate policy packages > > selinux-policy-strict (-source also) > - Containing pretty much the current policy > selinux-policy-targeted (-source also) At this time.. since a 'clean break' is desired and still fairly doable it would be a good idea to consider more than two policies -- the changes made now should at least consider the repercussions of sysadmins adding their own customized policies.. in parallel rather than over the top of these two. > 2. Both packages obsolete the current policy rpm. > > 3. We want both policy files to be installable and not conflict with > each other. > > 4. Policy files will be installed in the /etc/selinux/(strict|targeted) > directory. > Under this tree there will be at least three additional directiories These separated trees should be a general enough method for additional policies. > 5. Tools and libraries (fixfiles, libselinux, init, and setools) will be > modified to use the /etc/sysconfig/selinux file to determine which > policy to currently use on the system and where the policy files are > located. system-config-security should handle setting this and recognizing the presence of additional policies as well -- libselinux handles this for s-c-s? > 6. If during the install /etc/sysconfig/selinux does not exist or does > not contain an entry for the type of policy, the first one installed > will set the context to itself. On install it may be reasonable to set the context if the current value was unknown.. but it may be annoying if installing a default policy while a custom policy was in use. Perhaps a defined 'custom' option should be considered that these scripts would honor as valid, or the 'custom' name could be mandated to be an existing directory under /etc/security/selinux (meaning only that it is there rather than actually checking the contents of the directory in the rpm install script). > # Select the type of policy that you are running current values are > # strict and targeted # strict, targeted, or custom > # > SELINUXTYPE=strict Perhaps this consideration is something for the next 'clean break' instead of now, but it looks like a good time to handle is as generally as possible. -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lordmorgul on irc.freenode.net From fritz.elfert at millenux.com Wed May 26 10:45:53 2004 From: fritz.elfert at millenux.com (Fritz Elfert) Date: Wed, 26 May 2004 12:45:53 +0200 Subject: Proper local policy modifications - where? Message-ID: <200405261246.23773.fritz.elfert@millenux.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I got some special scripts which need a modified policy (/etc/dhclient-exit-hooks for example). So i'm wondering where to define local exceptions resp. additions without messing up the stuff from the policy-sources rpm. Is there any convention for adding local policies on FC2? If not, would it probably make sense to establish such a convention like e.g. /etc/security/selinux/policy.local? Thanks -Fritz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAtHV/boM4mAMyprARAh+iAKCGhtNJnmw8YAaYgMp/aZIQ3ArIOgCgiab2 DH+ItSMzlD56RS8HAE//vas= =kAmY -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed May 26 12:33:39 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 26 May 2004 08:33:39 -0400 Subject: New design for policy on disk allowing multiple policy rpms to be simultaniously installed. In-Reply-To: <1085548556.11149.20.camel@CirithUngol> References: <40B394AF.2000801@redhat.com> <1085548556.11149.20.camel@CirithUngol> Message-ID: <40B48EA3.50803@redhat.com> Andrew Farris wrote: >On Tue, 2004-05-25 at 14:47 -0400, Daniel J Walsh wrote: > > > >>1. We are breaking the policy file out into two separate policy packages >> >> selinux-policy-strict (-source also) >> - Containing pretty much the current policy >> selinux-policy-targeted (-source also) >> >> > >At this time.. since a 'clean break' is desired and still fairly doable >it would be a good idea to consider more than two policies -- the >changes made now should at least consider the repercussions of sysadmins >adding their own customized policies.. in parallel rather than over the >top of these two. > > > This design allows for more than two policies. Basically any directory name within /etc/selinux could be a policy. All that really happens is that libselinux will prepend /etc/selinux/POLICYTYPE and then postpend "policy" and "contexts" on the end and look for its files there. So you you define a POLICYTYPE=FarrisPolicy and setup /etc/selinux/FarrisPolicy/ correctly your policy will be used. >>2. Both packages obsolete the current policy rpm. >> >>3. We want both policy files to be installable and not conflict with >>each other. >> >>4. Policy files will be installed in the /etc/selinux/(strict|targeted) >>directory. >>Under this tree there will be at least three additional directiories >> >> > >These separated trees should be a general enough method for additional >policies. > > > They are >>5. Tools and libraries (fixfiles, libselinux, init, and setools) will be >>modified to use the /etc/sysconfig/selinux file to determine which >>policy to currently use on the system and where the policy files are >>located. >> >> > >system-config-security should handle setting this and recognizing the >presence of additional policies as well -- libselinux handles this for >s-c-s? > > > We can look into this. Basically allow the selection of all directories under /etc/selinux/. Or maybe make sure there is a policy and context file in each directory. >>6. If during the install /etc/sysconfig/selinux does not exist or does >>not contain an entry for the type of policy, the first one installed >>will set the context to itself. >> >> > >On install it may be reasonable to set the context if the current value >was unknown.. but it may be annoying if installing a default policy >while a custom policy was in use. Perhaps a defined 'custom' option >should be considered that these scripts would honor as valid, or the >'custom' name could be mandated to be an existing directory >under /etc/security/selinux (meaning only that it is there rather than >actually checking the contents of the directory in the rpm install >script). > > > Right so if you do not have POLICYTYPE set it will be set to the first policy RPM that is installed. If it is set then no RPM will change it. The user will have to manually change it. >># Select the type of policy that you are running current values are >># strict and targeted >> >> ># strict, targeted, or custom > > >># >>SELINUXTYPE=strict >> >> > >Perhaps this consideration is something for the next 'clean break' >instead of now, but it looks like a good time to handle is as generally >as possible. > > From bobgus at rcn.com Wed May 26 16:08:55 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Wed, 26 May 2004 11:08:55 -0500 Subject: Difficulty compiling setools-1.3-2 Message-ID: I downloaded 'setools-1.3-2.src.rpm' Using 'rpmbuild -bi', tried to build. This is near the bottom of the build output ... gcc -c replcon.c -DSUPPORTED_FILESYSTEMS='"ext2 ext3"' -Wall -O2 -I/usr/share -DDEFAULT_POLICY='"/etc/security/selinux/src/policy/policy.conf"' -DSEINFO_VERSION_NUM='"1.1"' -DSESEARCH_VERSION_NUM='"1.0"' -DREPLCON_VERSION_NUM='"1.0"' -DFINDCON_VERSION_NUM='"1.0"' -I.. -I../libapol replcon.c:16:29: selinux/selinux.h: No such file or directory replcon.c:17:29: selinux/context.h: No such file or directory replcon.c:299: error: syntax error before "get_security_context" replcon.c:300: warning: return type defaults to `int' replcon.c: In function `get_security_context': replcon.c:301: error: `security_context_t' undeclared (first use in this function) replcon.c:301: error: (Each undeclared identifier is reported only once replcon.c:301: error: for each function it appears in.) replcon.c:301: error: syntax error before "sec_con" replcon.c:304: error: `sec_con' undeclared (first use in this function) - ... Checking for the first missing file 'selinux.h' [root at hoho2 user1]# find / -name selinux.h -print /lib/modules/2.6.6-1.381smp/build/include/config/security/selinux.h /lib/modules/2.6.6-1.381/build/include/config/security/selinux.h /lib/modules/2.6.6-1.383/build/include/config/security/selinux.h /lib/modules/2.6.6-1.376/build/include/config/security/selinux.h /lib/modules/2.6.6-1.377/build/include/config/security/selinux.h /lib/modules/2.6.6-1.376smp/build/include/config/security/selinux.h /lib/modules/2.6.5-1.358smp/build/include/config/security/selinux.h /lib/modules/2.6.6-1.377smp/build/include/config/security/selinux.h /lib/modules/2.6.5-1.358/build/include/config/security/selinux.h /usr/src/linux-2.6.5-1.358/include/config/security/selinux.h [root at hoho2 user1]# (I need to trash some of those old kernels..) Don't see any selinux/selinux.h Also [root at hoho2 user1]# find / -name context.h -print /usr/src/linux-2.6.5-1.358/security/selinux/ss/context.h /old/usr/local/src/OO/OpenOffice.org1.1_SDK/include/bridges/remote/context.h [root at hoho2 user1]# Don't see any selinux/context.h either ----- The binary of that package is installed [root at hoho2 sel]# rpm -q setools setools-1.3-2 [root at hoho2 sel]# But many of the setools pieces are not in that binary package (apol, awish,..) Maybe they never got built? [root at hoho2 sel]# cd /var/cache/yum [root at hoho2 yum]# ls base development updates-released updates-testing [root at hoho2 yum]# find . -name setools\*.rpm -print ./base/packages/setools-1.3-2.i386.rpm [root at hoho2 yum]# rpm -q -l -p base/packages/setools-1.3-2.i386.rpm /usr/bin/seinfo /usr/bin/sepcut /usr/bin/sesearch /usr/bin/seuser /usr/bin/seuseradd /usr/bin/seuserdel /usr/bin/seusermod /usr/share/doc/setools-1.3/KNOWN-BUGS /usr/share/doc/setools-1.3/README /usr/share/doc/setools-1.3/apol_help.txt /usr/share/doc/setools-1.3/apol_perm_mapping_ver12 /usr/share/doc/setools-1.3/apol_perm_mapping_ver15 /usr/share/doc/setools-1.3/apol_perm_mapping_ver16 /usr/share/doc/setools-1.3/apol_perm_mapping_ver17 /usr/share/doc/setools-1.3/dta_help.txt /usr/share/doc/setools-1.3/iflow_help.txt /usr/share/doc/setools-1.3/obj_perms_help.txt /usr/share/doc/setools-1.3/seaudit_help.txt /usr/share/doc/setools-1.3/sepcut_help.txt /usr/share/doc/setools-1.3/seuser_help.txt /usr/share/setools/apol.tcl /usr/share/setools/apol_help.txt /usr/share/setools/apol_perm_mapping /usr/share/setools/apol_perm_mapping_ver12 /usr/share/setools/apol_perm_mapping_ver15 /usr/share/setools/apol_perm_mapping_ver16 /usr/share/setools/apol_perm_mapping_ver17 /usr/share/setools/customize_filter_window.glade /usr/share/setools/dot_seaudit /usr/share/setools/dta_help.txt /usr/share/setools/filter_window.glade /usr/share/setools/iflow_help.txt /usr/share/setools/multifilter_window.glade /usr/share/setools/obj_perms_help.txt /usr/share/setools/prefer_window.glade /usr/share/setools/query_window.glade /usr/share/setools/se_user.tcl /usr/share/setools/seaudit.glade /usr/share/setools/seaudit_help.txt /usr/share/setools/sepcut_help.txt /usr/share/setools/seuser.conf /usr/share/setools/seuser_help.txt [root at hoho2 yum]# From sds at epoch.ncsc.mil Wed May 26 16:13:12 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 26 May 2004 12:13:12 -0400 Subject: Difficulty compiling setools-1.3-2 In-Reply-To: References: Message-ID: <1085587992.31854.77.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-05-26 at 12:08, Bob Gustafson wrote: > I downloaded 'setools-1.3-2.src.rpm' I'd recommend downloading the source tarball from the Tresys site or the NSA site for setools-1.3.1, unless Dan has already incorporated those changes into his SRPM. > Checking for the first missing file 'selinux.h' You need to do a 'yum install libselinux-devel'. -- Stephen Smalley National Security Agency From Valdis.Kletnieks at vt.edu Wed May 26 16:26:01 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 26 May 2004 12:26:01 -0400 Subject: mysql issues... In-Reply-To: Your message of "Wed, 26 May 2004 14:17:40 +1000." <200405261417.40958.russell@coker.com.au> References: <200405250215.i4P2FFAe027848@turing-police.cc.vt.edu> <200405261417.40958.russell@coker.com.au> Message-ID: <200405261626.i4QGQ1GQ001031@turing-police.cc.vt.edu> On Wed, 26 May 2004 14:17:40 +1000, Russell Coker said: > How should we determine who gets mysql client access? Should we have a > tunable determining whether we allow userdomain? That might be a good solution.. > Why have mysql_cmd_t instead of just allowing user_t directly? What is the > benefit in having a domain for client access? Thinko on my part - I invented the cmd_t because I'd been fighting various issues for about 14 hours at that point, and didn't parse through mysqld.te, apache.te, and mysqld.fc sufficiently to realize that the var_run_t was identical in semantics (somehow, I was convince that var_run_t included something I didn't want in cmd_t, but that was wrong). How do people feel about the attached patch to add a tunable? -------------- next part -------------- --- macros/user_macros.te.dist 2004-05-11 11:03:38.000000000 -0400 +++ macros/user_macros.te 2004-05-26 12:22:18.852047888 -0400 @@ -242,6 +242,14 @@ r_dir_file($1_t, mnt_t) ') +ifdef(`user_mysql',` +# +# Allow users to access the mysql socket +# +allow $1_t mysqld_var_run_t:dir search; +allow $1_t mysqld_var_run_t:sock_file write; +') + # # Rules used to associate a homedir as a mountpoint # --- tunable.te.dist 2004-05-11 11:03:38.000000000 -0400 +++ tunable.te 2004-05-26 12:19:33.221383912 -0400 @@ -99,3 +99,6 @@ # Allow user to rw usb devices define(`user_rw_usb') + +# Allow users to access mysql +define(`user_mysql') -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From sds at epoch.ncsc.mil Wed May 26 16:31:52 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 26 May 2004 12:31:52 -0400 Subject: mysql issues... In-Reply-To: <200405261417.40958.russell@coker.com.au> References: <200405250215.i4P2FFAe027848@turing-police.cc.vt.edu> <200405261417.40958.russell@coker.com.au> Message-ID: <1085589112.31854.86.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-05-26 at 00:17, Russell Coker wrote: > Why have mysql_cmd_t instead of just allowing user_t directly? What is the > benefit in having a domain for client access? Is the client program setgid or setuid presently to give it more access? If so, then a separate domain is reasonable. Regardless, there is a potential advantage in limiting access to the client program, e.g. you can ensure that only well-formed messages constructed by the client program are sent on that socket as opposed to arbitrary data from the user. Naturally, it all depends on what you are trying to protect and what threats you want to counter. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Wed May 26 16:56:03 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 26 May 2004 12:56:03 -0400 Subject: New design for policy on disk allowing multiple policy rpms to be simultaniously installed. In-Reply-To: <40B39C09.5040300@nc.rr.com> References: <40B394AF.2000801@redhat.com> <40B39C09.5040300@nc.rr.com> Message-ID: <1085590563.31854.95.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2004-05-25 at 15:18, Jeff Johnson wrote: > Well, the existing means to handle simultaneous installs of otherwise > mutually exclusive packages is the > alternatives mechanism used to handle sendmail vs. postfix and lpd vs. cups. > > Yes, symlinks, feeble, but that is the existing mechanism, might as well > use if in the distro. Can you elaborate on how this works presently? How do you avoid conflicts among multiple packages owning those symlinks? -- Stephen Smalley National Security Agency From bobgus at rcn.com Wed May 26 18:01:31 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Wed, 26 May 2004 13:01:31 -0500 Subject: Difficulty compiling setools-1.3-2 In-Reply-To: <1085587992.31854.77.camel@moss-spartans.epoch.ncsc.mil> References: Message-ID: Thanks much, seems to work (I have a blank apol window popped up on my screen) The Tresys version of setools-1.3.1.tgz is bigger and newer than the one on the NSA site. BobG On Wed, 26 May 2004 12:13:12 -0400, Stephen Smalley wrote: >On Wed, 2004-05-26 at 12:08, Bob Gustafson wrote: >> I downloaded 'setools-1.3-2.src.rpm' > >I'd recommend downloading the source tarball from the Tresys site or the >NSA site for setools-1.3.1, unless Dan has already incorporated those >changes into his SRPM. > >> Checking for the first missing file 'selinux.h' > >You need to do a 'yum install libselinux-devel'. > >-- >Stephen Smalley >National Security Agency From sds at epoch.ncsc.mil Wed May 26 18:07:30 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 26 May 2004 14:07:30 -0400 Subject: Difficulty compiling setools-1.3-2 In-Reply-To: References: Message-ID: <1085594849.31854.105.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-05-26 at 14:01, Bob Gustafson wrote: > Thanks much, seems to work (I have a blank apol window popped up on my screen) > > The Tresys version of setools-1.3.1.tgz is bigger and newer than the one on > the NSA site. diff -ru on the expanded directories shows that the only difference is that the Tresys tarball has a spurious Attic directory under seuser. The tarball on the NSA site is built from our internal CVS tree, and we import new versions from Tresys as appropriate (but naturally don't import CVS internal files like the Attic directory). -- Stephen Smalley National Security Agency From aleksey at nogin.org Wed May 26 21:13:45 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Wed, 26 May 2004 14:13:45 -0700 Subject: Proper local policy modifications - where? In-Reply-To: <200405261246.23773.fritz.elfert@millenux.com> References: <200405261246.23773.fritz.elfert@millenux.com> Message-ID: <40B50889.6030709@nogin.org> On 26.05.2004 03:45, Fritz Elfert wrote: > I got some special scripts which need a modified policy > (/etc/dhclient-exit-hooks for example). So i'm wondering where to define > local exceptions resp. additions without messing up the stuff from the > policy-sources rpm. Is there any convention for adding local policies on FC2? > If not, would it probably make sense to establish such a convention like > e.g. /etc/security/selinux/policy.local? See the thread at http://www.redhat.com/archives/fedora-selinux-list/2004-April/msg00232.html -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From bobgus at rcn.com Thu May 27 00:33:44 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Wed, 26 May 2004 19:33:44 -0500 Subject: Difficulty compiling setools-1.3-2 In-Reply-To: <1085594849.31854.105.camel@moss-spartans.epoch.ncsc.mil> References: Message-ID: I did a little more testing [user1 at hoho2 user1]$ seuser show users Could not access policy.conf file. Verify the location is valid in the seuser.co nf file. [user1 at hoho2 user1]$ At this point, I said 'whoops, remake of setools has same problem as before' But then a minute later, when I was logged in as root, I did it again with good results - no code change. [root at hoho2 user1]# [root at hoho2 user1]# seuser show users system_u: system_r user_u: user_r sysadm_r system_r root: staff_r sysadm_r system_r cyrus: cyrus_r mailman: mailman_r [root at hoho2 user1]# I don't know what the desired error message is for an ordinary user? Are mortal users discouraged from running seuser? If so, perhaps the policy should just make it not executable for mortal users. If mortal users can run 'seuser', then perhaps the seuser.conf file has to be accessible to the seuser program when being run by a mortal user. That is my guess at why the error message comes up. BobG On Wed, 26 May 2004 14:07:30 -0400, Stephen Smalley wrote: >On Wed, 2004-05-26 at 14:01, Bob Gustafson wrote: >> Thanks much, seems to work (I have a blank apol window popped up on my >>screen) >> >> The Tresys version of setools-1.3.1.tgz is bigger and newer than the one on >> the NSA site. > >diff -ru on the expanded directories shows that the only difference is >that the Tresys tarball has a spurious Attic directory under seuser. >The tarball on the NSA site is built from our internal CVS tree, and we >import new versions from Tresys as appropriate (but naturally don't >import CVS internal files like the Attic directory). > >-- >Stephen Smalley >National Security Agency > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list From n3npq at nc.rr.com Thu May 27 00:45:27 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 26 May 2004 20:45:27 -0400 Subject: New design for policy on disk allowing multiple policy rpms to be simultaniously installed. In-Reply-To: <1085590563.31854.95.camel@moss-spartans.epoch.ncsc.mil> References: <40B394AF.2000801@redhat.com> <40B39C09.5040300@nc.rr.com> <1085590563.31854.95.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <40B53A27.9070709@nc.rr.com> Stephen Smalley wrote: >On Tue, 2004-05-25 at 15:18, Jeff Johnson wrote: > > >>Well, the existing means to handle simultaneous installs of otherwise >>mutually exclusive packages is the >>alternatives mechanism used to handle sendmail vs. postfix and lpd vs. cups. >> >>Yes, symlinks, feeble, but that is the existing mechanism, might as well >>use if in the distro. >> >> > >Can you elaborate on how this works presently? How do you avoid >conflicts among multiple packages owning those symlinks? > > > Sure. sendmail and postfix are mutually conflicting because both wish to use /usr/lib/sendmail. So the path is a symlink, conflicts avoided because the symlink is not part of any package, but rather a side effect of the install: $ rpm -qf /usr/lib/sendmail file /usr/lib/sendmail is not owned by any package See also "man alternatives". Here are the scripts from the sendmail package, edited to remove "other stuff": $ rpm -q --scripts sendmail postinstall scriptlet (using /bin/sh): # # Set up the alternatives files for MTAs. # /usr/sbin/alternatives --install /usr/sbin/sendmail mta /usr/sbin/sendmail.sendmail 90 \ --slave /usr/bin/mailq mta-mailq /usr/bin/mailq.sendmail \ --slave /usr/bin/newaliases mta-newaliases /usr/bin/newaliases.sendmail \ --slave /usr/bin/rmail mta-rmail /usr/bin/rmail.sendmail \ --slave /usr/lib/sendmail mta-sendmail /usr/lib/sendmail.sendmail \ --slave /etc/pam.d/smtp mta-pam /etc/pam.d/smtp.sendmail \ --slave /usr/share/man/man8/sendmail.8.gz mta-sendmailman /usr/share/man/man8/sendmail.sendmail.8.gz \ --slave /usr/share/man/man1/mailq.1.gz mta-mailqman /usr/share/man/man1/mailq.sendmail.1.gz \ --slave /usr/share/man/man1/newaliases.1.gz mta-newaliasesman /usr/share/man/man1/newaliases.sendmail.1.gz \ --slave /usr/share/man/man5/aliases.5.gz mta-aliasesman /usr/share/man/man5/aliases.sendmail.5.gz \ --initscript sendmail preuninstall scriptlet (using /bin/sh): if [ $1 = 0 ]; then /usr/sbin/alternatives --remove mta /usr/sbin/sendmail.sendmail fi exit 0 postuninstall scriptlet (using /bin/sh): if [ "$1" -ge "1" ]; then mta=`readlink /etc/alternatives/mta` if [ "$mta" == "/usr/sbin/sendmail.sendmail" ]; then /usr/sbin/alternatives --set mta /usr/sbin/sendmail.sendmail fi fi exit 0 HTH 73 de Jeff From selinux at comcast.net Thu May 27 01:06:19 2004 From: selinux at comcast.net (Tom London) Date: Wed, 26 May 2004 18:06:19 -0700 Subject: relabeling of libjava plugin (j2sdk_1_5_0) Message-ID: <40B53F0B.6000300@comcast.net> I've installed j2sdk_1_5_0 following the usual Fedora instruction. The only adder is that the mozilla plugin needs its context 'fixed'. Here's what I do: cd /usr/lib/mozilla/plugins chcon --reference moz* libjava* chcon -h --reference moz* libjava* (not sure this is needed) (/usr/lib/mozilla/plugins/libjava* is a symbolic link to /usr/java/j2sdk1.5.0/jre/plugin/i386/ns7/libjavaplugin_oji.so). That seems to make the plugin work. After yum updating some packages, I ran 'fixfiles relabel' and found that it undid the context change above. Here are the log entries: /usr/sbin/setfiles: relabeling /usr/lib/mozilla/plugins/libjavaplugin_oji.so from system_u:object_r:shlib_t to system_u:object_r:lib_t /usr/sbin/setfiles: relabeling /usr/java/j2sdk1.5.0/jre/plugin/i386/ns7/libjavaplugin_oji.so from system_u:object_r:shlib_t to system_u:object_r:usr_t After this, the java-vm plugin stops working (that is, web pages with x-java-vm items no longer work). I run the chcon's again and all works. Does src/policy/file_contexts/types.fc need a line for it? (e.g., /usr/java/j2sdk.*/jre/plugin/i386(/.*)?/lib.*\.so.* -- system_u:object_r:shlib_t) thanks, tom From parklee_fcsel at yahoo.com Thu May 27 06:44:47 2004 From: parklee_fcsel at yahoo.com (park lee) Date: Wed, 26 May 2004 23:44:47 -0700 (PDT) Subject: How to make SELinux in Fedora work? Message-ID: <20040527064447.14920.qmail@web90109.mail.scd.yahoo.com> Hi, I've downloaded Fedora Core 2 from http://fedora.redhat.com/download/, and have installed it successfully. When I type the command: ls -Z. The command failed, and FC2 send me a message on screen that this command can only be run on SELinux core. Then , I want to ask how to run SELinux which is integrated into Fedora Core? Is there some resources about what to do and how to do ? And Is there any differences between it and the SELinux from http://www.nsa.gov/selinux/code/download5.cfm. As i know ,when we want to run the SELinux from ttp://www.nsa.gov/selinux/code/download5.cfm.we should first recompile the kernel with certain options, then install some applications (such as checkpolicy, libselinux) from the SELinux Full Userland Archive to the system. Then , if we want to run the SELinux that is integrated into Fedora Core, should we do the same steps? Thank you very much for your help! Yours, Park Lee 2004-05-27 --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhally at mindspring.com Thu May 27 07:15:56 2004 From: rhally at mindspring.com (Richard Hally) Date: Thu, 27 May 2004 03:15:56 -0400 Subject: How to make SELinux in Fedora work? In-Reply-To: <20040527064447.14920.qmail@web90109.mail.scd.yahoo.com> References: <20040527064447.14920.qmail@web90109.mail.scd.yahoo.com> Message-ID: <40B595AC.4000703@mindspring.com> park lee wrote: > Hi, > > I've downloaded Fedora Core 2 from http://fedora.redhat.com/download/, > and have installed it successfully. > > When I type the command: ls -Z. > The command failed, and FC2 send me a message on screen that this > command can only be run on SELinux core. > > Then , I want to ask how to run SELinux which is integrated into Fedora > Core? Is there some resources about what to do and how to do ? > > And Is there any differences between it and the SELinux from > http://www.nsa.gov/selinux/code/download5.cfm. As i know ,when we want > to run the SELinux from ttp://www.nsa.gov/selinux/code/download5.cfm > .we should first > recompile the kernel with certain options, then install some > applications (such as checkpolicy, libselinux) from the SELinux Full > Userland Archive > to the > system. Then , if we want to run the SELinux that is integrated into > Fedora Core, should we do the same steps? > > Thank you very much for your help! > > Yours, > Park Lee > 2004-05-27 > > > ------------------------------------------------------------------------ > Do you Yahoo!? > Friends. Fun. Try the all-new Yahoo! Messenger > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list Here is a link to the FAQ to get you started: http://people.redhat.com/kwade/selinux/fc2test2-selinux-rn-en/selinux-faq-en/ Hope This Helps, Richard Hally From parklee_fcsel at yahoo.com Thu May 27 08:15:24 2004 From: parklee_fcsel at yahoo.com (park lee) Date: Thu, 27 May 2004 01:15:24 -0700 (PDT) Subject: How to make SELinux in Fedora work? In-Reply-To: <40B595AC.4000703@mindspring.com> Message-ID: <20040527081524.78036.qmail@web90106.mail.scd.yahoo.com> Richard Hally wrote:park lee wrote: > Hi, > > I've downloaded Fedora Core 2 from http://fedora.redhat.com/download/, > and have installed it successfully. > > When I type the command: ls -Z. > The command failed, and FC2 send me a message on screen that this > command can only be run on SELinux core. > > Then , I want to ask how to run SELinux which is integrated into Fedora > Core? Is there some resources about what to do and how to do ? > > And Is there any differences between it and the SELinux from > http://www.nsa.gov/selinux/code/download5.cfm. As i know ,when we want > to run the SELinux from ttp://www.nsa.gov/selinux/code/download5.cfm > .we should first > recompile the kernel with certain options, then install some > applications (such as checkpolicy, libselinux) from the SELinux Full > Userland Archive > to the > system. Then , if we want to run the SELinux that is integrated into > Fedora Core, should we do the same steps? > > Thank you very much for your help! > > Yours, > Park Lee > 2004-05-27 > > > ------------------------------------------------------------------------ > Do you Yahoo!? > Friends. Fun. Try the all-new Yahoo! Messenger > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list Here is a link to the FAQ to get you started: http://people.redhat.com/kwade/selinux/fc2test2-selinux-rn-en/selinux-faq-en/ Hope This Helps, Richard Hally -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.east at iue.it Thu May 27 08:39:24 2004 From: matthew.east at iue.it (Matthew East) Date: Thu, 27 May 2004 10:39:24 +0200 Subject: Permission denied when building kernel Message-ID: <1085612449.1965.1.camel@localhost> I cannot build and install a kernel with selinux enabled. Here is what happens towards the end of the modules_install stage: if [ -r System.map ]; then /sbin/depmod -ae -F System.map -b /var/tmp/kernel-2.6.6-root -r 2.6.6; fi WARNING: Couldn't open directory /var/tmp/kernel-2.6.6-root/lib/modules/2.6.6: Permission denied FATAL: Could not open /var/tmp/kernel-2.6.6-root/lib/modules/2.6.6/modules.dep.temp for writing: Permission denied make[1]: *** [_modinst_post] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.11877 (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.11877 (%install) make: *** [rpm] Error 1 Here are the error messages: [root at localhost linux-2.6.6]# dmesg |tail {snip} audit(1085609097.359:0): avc: denied { search } for pid=17414 exe=/sbin/depmod name=tmp dev=hda2 ino=196228 scontext=root:sysadm_r:depmod_t tcontext=system_u:object_r:tmp_t tclass=dir audit(1085609097.359:0): avc: denied { search } for pid=17414 exe=/sbin/depmod name=tmp dev=hda2 ino=196228 scontext=root:sysadm_r:depmod_t tcontext=system_u:object_r:tmp_t tclass=dir I hope that someone can help me with this!! Maybe I am going about the compiling the wrong way, but it works fine with selinux disabled. Many thanks in advance, Matt p.s. Just for the record, or in case they are useful, here are the error messages I get when booting my new kernel which was compiled with selinux set to permissive. Freeing unused kernel memory: 160k freed security: 5 users, 7 roles, 1244 types, 1 bools security: 30 classes, 303377 rules SELinux: Completing initialization. SELinux: Setting up existing superblocks. SELinux: initialized (dev , type selinuxfs), uses genfs_contexts SELinux: initialized (dev hda2, type ext3), uses xattr audit(1085619351.268:0): avc: denied { ioctl } for pid=164 exe=/bin/bash path=/dev/null dev=hda2 ino=283937 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file audit(1085619351.271:0): avc: denied { getattr } for pid=176 exe=/bin/bash path=/etc/hotplug dev=hda2 ino=49185 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1085619351.271:0): avc: denied { read } for pid=164 exe=/bin/bash path=pipe:[842] dev= ino=842 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=fifo_file audit(1085619351.272:0): avc: denied { ioctl } for pid=165 exe=/bin/bash path=/dev/null dev=hda2 ino=283937 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file audit(1085619351.274:0): avc: denied { search } for pid=177 exe=/bin/bash name=hotplug dev=hda2 ino=49185 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1085619351.274:0): avc: denied { read } for pid=165 exe=/bin/bash path=pipe:[843] dev= ino=843 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=fifo_file audit(1085619351.274:0): avc: denied { ioctl } for pid=167 exe=/bin/bash path=/dev/null dev=hda2 ino=283937 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file audit(1085619351.277:0): avc: denied { search } for pid=178 exe=/bin/bash name=hotplug dev=hda2 ino=49185 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1085619351.277:0): avc: denied { read } for pid=167 exe=/bin/bash path=pipe:[844] dev= ino=844 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=fifo_file audit(1085619351.277:0): avc: denied { ioctl } for pid=166 exe=/bin/bash path=/dev/null dev=hda2 ino=283937 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file audit(1085619351.280:0): avc: denied { search } for pid=179 exe=/bin/bash name=hotplug dev=hda2 ino=49185 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1085619351.280:0): avc: denied { read } for pid=166 exe=/bin/bash path=pipe:[845] dev= ino=845 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=fifo_file audit(1085619351.290:0): avc: denied { getattr } for pid=177 exe=/bin/env path=/etc/ld.so.cache dev=hda2 ino=50220 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=file audit(1085619351.290:0): avc: denied { read } for pid=177 exe=/bin/env name=libc-2.3.3.so dev=hda2 ino=131669 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=file audit(1085619351.290:0): avc: denied { getattr } for pid=177 exe=/bin/env path=/lib/tls dev=hda2 ino=130821 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1085619351.290:0): avc: denied { read } for pid=176 exe=/bin/bash path=/lib/ld-2.3.3.so dev=hda2 ino=130827 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=file audit(1085619351.290:0): avc: denied { getattr } for pid=176 exe=/bin/bash path=/dev/null dev=hda2 ino=283937 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file audit(1085619351.291:0): avc: denied { write } for pid=176 exe=/bin/bash path=/dev/null dev=hda2 ino=283937 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file audit(1085619351.292:0): avc: denied { search } for pid=164 exe=/bin/bash name=hotplug dev=hda2 ino=49185 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1085619351.292:0): avc: denied { read } for pid=179 exe=/bin/bash path=/lib/ld-2.3.3.so dev=hda2 ino=130827 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=file audit(1085619351.293:0): avc: denied { getattr } for pid=179 exe=/bin/bash path=/dev/null dev=hda2 ino=283937 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file audit(1085619351.293:0): avc: denied { write } for pid=179 exe=/bin/bash path=/dev/null dev=hda2 ino=283937 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file audit(1085619351.294:0): avc: denied { search } for pid=166 exe=/bin/bash name=hotplug dev=hda2 ino=49185 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1085619351.294:0): avc: denied { read } for pid=178 exe=/bin/bash path=/lib/ld-2.3.3.so dev=hda2 ino=130827 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=file audit(1085619351.294:0): avc: denied { getattr } for pid=178 exe=/bin/bash path=/dev/null dev=hda2 ino=283937 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file audit(1085619351.295:0): avc: denied { write } for pid=178 exe=/bin/bash path=/dev/null dev=hda2 ino=283937 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file audit(1085619351.296:0): avc: denied { search } for pid=167 exe=/bin/bash name=hotplug dev=hda2 ino=49185 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1085619351.699:0): avc: denied { getattr } for pid=177 exe=/bin/env path=pipe:[843] dev= ino=843 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=fifo_file audit(1085619351.700:0): avc: denied { write } for pid=177 exe=/bin/env path=pipe:[843] dev= ino=843 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=fifo_file SELinux: initialized (dev ram0, type ext2), uses xattr SELinux: initialized (dev , type mqueue), not configured for labeling SELinux: initialized (dev , type hugetlbfs), not configured for labeling SELinux: initialized (dev , type devpts), uses transition SIDs SELinux: initialized (dev , type eventpollfs), uses genfs_contexts SELinux: initialized (dev , type pipefs), uses task SIDs SELinux: initialized (dev , type tmpfs), uses transition SIDs SELinux: initialized (dev , type futexfs), uses genfs_contexts SELinux: initialized (dev , type sockfs), uses task SIDs SELinux: initialized (dev , type proc), uses genfs_contexts SELinux: initialized (dev , type bdev), uses genfs_contexts SELinux: initialized (dev , type rootfs), uses genfs_contexts SELinux: initialized (dev , type sysfs), uses genfs_contexts From dwalsh at redhat.com Thu May 27 11:54:46 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 27 May 2004 07:54:46 -0400 Subject: Security contexts for the contexts directory? Message-ID: <40B5D706.2050902@redhat.com> With the new design of the policy tree, we have moved the "contexts" files into /etc/selinux/*/contexts/ These files include default_contexts, file_contexts, default_type, failsafe_contexts ... as well as contexts for individual users like users/root. Currently the security contexts for these files is etc_t. Should we change them so something else? default_contexts_t? Should file_contexts be marked differently then the others? Also since policy is determined by /etc/sysconfig/selinux, should we set a special security context on it? If we do should we move it to a directory where it would be easier to maintain the security context? Maybe rename it to /etc/selinux/config? Dan From sds at epoch.ncsc.mil Thu May 27 12:16:03 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 27 May 2004 08:16:03 -0400 Subject: How to make SELinux in Fedora work? In-Reply-To: <20040527064447.14920.qmail@web90109.mail.scd.yahoo.com> References: <20040527064447.14920.qmail@web90109.mail.scd.yahoo.com> Message-ID: <1085660163.1072.84.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-05-27 at 02:44, park lee wrote: > I've downloaded Fedora Core 2 from http://fedora.redhat.com/download/, > and have installed it successfully. As noted in the release notes for FC2 (http://fedora.redhat.com/docs/release-notes/), you have to pass "selinux" to the installer to enable SELinux at install time. > Then , I want to ask how to run SELinux which is integrated into > Fedora Core? Is there some resources about what to do and how to do ? If you didn't enable SELinux at install time, then you'll need to install a policy (yum install policy policy-sources), create or edit /etc/sysconfig/selinux and set SELINUX=permissive in it, and relabel your filesystems (via fixfiles relabel). Once you get your filesystems labeled and have verified that you can boot without avc denials in your logs, you can set SELINUX=enforcing in /etc/sysconfig/selinux. > And Is there any differences between it and the SELinux from > http://www.nsa.gov/selinux/code/download5.cfm. As i know ,when we want > to run the SELinux from > ttp://www.nsa.gov/selinux/code/download5.cfm.we should first recompile > the kernel with certain options, then install some applications (such > as checkpolicy, libselinux) from the SELinux Full Userland Archive to > the system. Then , if we want to run the SELinux that is integrated > into Fedora Core, should we do the same steps? Fedora Core 2 already includes the SELinux code in the kernel and applications, so you don't have to recompile anything. You just need to enable the SELinux support that is already there. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Thu May 27 12:45:19 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 27 May 2004 08:45:19 -0400 Subject: Permission denied when building kernel In-Reply-To: <1085612449.1965.1.camel@localhost> References: <1085612449.1965.1.camel@localhost> Message-ID: <1085661919.1072.115.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-05-27 at 04:39, Matthew East wrote: > I cannot build and install a kernel with selinux enabled. Here is what > happens towards the end of the modules_install stage: > if [ -r System.map ]; then /sbin/depmod -ae -F System.map -b > /var/tmp/kernel-2.6.6-root -r 2.6.6; fi > WARNING: Couldn't open directory > /var/tmp/kernel-2.6.6-root/lib/modules/2.6.6: Permission denied > FATAL: Could not open > /var/tmp/kernel-2.6.6-root/lib/modules/2.6.6/modules.dep.temp for > writing: Permission denied > make[1]: *** [_modinst_post] Error 1 > error: Bad exit status from /var/tmp/rpm-tmp.11877 (%install) Add 'tmp_domain(depmod)' to /etc/security/selinux/src/policy/domains/program/modutils.te and do a 'make load' in /etc/security/selinux/src/policy. yum install policy-sources if you don't already have it. > p.s. Just for the record, or in case they are useful, here are the error > messages I get when booting my new kernel which was compiled with > selinux set to permissive. > > Freeing unused kernel memory: 160k freed > security: 5 users, 7 roles, 1244 types, 1 bools > security: 30 classes, 303377 rules > SELinux: Completing initialization. > SELinux: Setting up existing superblocks. > SELinux: initialized (dev , type selinuxfs), uses genfs_contexts > SELinux: initialized (dev hda2, type ext3), uses xattr > audit(1085619351.268:0): avc: denied { ioctl } for pid=164 > exe=/bin/bash path=/dev/null dev=hda2 ino=283937 > scontext=system_u:system_r:kernel_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > audit(1085619351.271:0): avc: denied { getattr } for pid=176 > exe=/bin/bash path=/etc/hotplug dev=hda2 ino=49185 > scontext=system_u:system_r:kernel_t > tcontext=system_u:object_r:unlabeled_t tclass=dir Very odd; these certainly shouldn't be unlabeled_t. What does a getfilecon /etc/hotplug (or any of these files that are showing up with unlabeled_t) show? -- Stephen Smalley National Security Agency From kmacmillan at tresys.com Thu May 27 12:48:27 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Thu, 27 May 2004 08:48:27 -0400 Subject: Difficulty compiling setools-1.3-2 In-Reply-To: <1085594849.31854.105.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200405271248.i4RCm5Sf009616@gotham.columbia.tresys.com> > -----Original Message----- > From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list- > bounces at redhat.com] On Behalf Of Stephen Smalley > Sent: Wednesday, May 26, 2004 2:08 PM > To: Fedora SELinux support list for users & developers. > Subject: Re: Difficulty compiling setools-1.3-2 > > On Wed, 2004-05-26 at 14:01, Bob Gustafson wrote: > > Thanks much, seems to work (I have a blank apol window popped up on my > screen) > > > > The Tresys version of setools-1.3.1.tgz is bigger and newer than the one > on > > the NSA site. > > diff -ru on the expanded directories shows that the only difference is > that the Tresys tarball has a spurious Attic directory under seuser. > The tarball on the NSA site is built from our internal CVS tree, and we > import new versions from Tresys as appropriate (but naturally don't > import CVS internal files like the Attic directory). > As Steve says, the Attic directory was simply an error in making our release tarball. You can ignore it without problems. Karl Karl MacMillan Tresys Technology http://www.tresys.com (410)290-1411 ext 134 > -- > Stephen Smalley > National Security Agency > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From sds at epoch.ncsc.mil Thu May 27 13:16:12 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 27 May 2004 09:16:12 -0400 Subject: Security contexts for the contexts directory? In-Reply-To: <40B5D706.2050902@redhat.com> References: <40B5D706.2050902@redhat.com> Message-ID: <1085663772.1072.149.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-05-27 at 07:54, Daniel J Walsh wrote: > With the new design of the policy tree, we have moved the "contexts" > files into > /etc/selinux/*/contexts/ > > These files include default_contexts, file_contexts, default_type, > failsafe_contexts ... > as well as contexts for individual users like users/root. Currently the > security contexts for these files is etc_t. Should we change them so > something else? default_contexts_t? Should file_contexts be marked > differently then the others? I'd suggest a single type (other than etc_t) for default_contexts, default_type, failsafe_context, and the other files installed from policy/appconfig. file_contexts should likely have a different type to allow different access, so perhaps it should have its own directory and type. With the old layout and policy, it ends up in policy_config_t, but I think we want to distinguish it from the binary policy file as well as from the appconfig files. > Also since policy is determined by /etc/sysconfig/selinux, should we set > a special security context on it? If we do should we move it to a > directory where it would be easier to maintain the security context? > Maybe rename it to /etc/selinux/config? I would prefer having a distinct type on it (and moving it to a directory with that type so that we can easily preserve the type), as the integrity of that file is critical to SELinux, at least in the Fedora Core implementation. -- Stephen Smalley National Security Agency From kmacmillan at tresys.com Thu May 27 13:55:34 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Thu, 27 May 2004 09:55:34 -0400 Subject: Difficulty compiling setools-1.3-2 In-Reply-To: Message-ID: <200405271355.i4RDtBSf009915@gotham.columbia.tresys.com> > -----Original Message----- > From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list- > bounces at redhat.com] On Behalf Of Bob Gustafson > Sent: Wednesday, May 26, 2004 8:34 PM > To: Fedora SELinux support list for users & developers. > Subject: Re: Difficulty compiling setools-1.3-2 > > I did a little more testing > > [user1 at hoho2 user1]$ seuser show users > Could not access policy.conf file. Verify the location is valid in the > seuser.co > nf file. > [user1 at hoho2 user1]$ > > At this point, I said 'whoops, remake of setools has same problem as > before' > > But then a minute later, when I was logged in as root, I did it again with > good results - no code change. > > [root at hoho2 user1]# > [root at hoho2 user1]# seuser show users > > system_u: system_r > user_u: user_r sysadm_r system_r > root: staff_r sysadm_r system_r > cyrus: cyrus_r > mailman: mailman_r > > > [root at hoho2 user1]# > > I don't know what the desired error message is for an ordinary user? I'm not certain either, but the error message that was returned was clearly no the right one. We'll work on some better error messages for a future release. > Are > mortal users discouraged from running seuser? If so, perhaps the policy > should just make it not executable for mortal users. > > If mortal users can run 'seuser', then perhaps the seuser.conf file has to > be accessible to the seuser program when being run by a mortal user. That > is my guess at why the error message comes up. > That is correct. Seuser is designed to only be run by sysadm_r - it is a trusted program with wide ranging access to the policy, so it is probably not appropriate for a normal user to run (this is all in the context of the strict policy - things are different under the targeted policy). If you simply what to see the users in the system, the better program to use is seinfo: [kmacmillan at pham setools-1.4]$ seinfo -u -x Users: 5 system_u system_r root system_r sysadm_r staff_r user_u system_r sysadm_r user_r cyrus cyrus_r mailman mailman_r Karl > > BobG > > > > On Wed, 26 May 2004 14:07:30 -0400, Stephen Smalley wrote: > >On Wed, 2004-05-26 at 14:01, Bob Gustafson wrote: > >> Thanks much, seems to work (I have a blank apol window popped up on my > >>screen) > >> > >> The Tresys version of setools-1.3.1.tgz is bigger and newer than the > one on > >> the NSA site. > > > >diff -ru on the expanded directories shows that the only difference is > >that the Tresys tarball has a spurious Attic directory under seuser. > >The tarball on the NSA site is built from our internal CVS tree, and we > >import new versions from Tresys as appropriate (but naturally don't > >import CVS internal files like the Attic directory). > > > >-- > >Stephen Smalley > >National Security Agency > > > >-- > >fedora-selinux-list mailing list > >fedora-selinux-list at redhat.com > >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Thu May 27 13:54:44 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 27 May 2004 09:54:44 -0400 Subject: Security contexts for the contexts directory? In-Reply-To: <1085663772.1072.149.camel@moss-spartans.epoch.ncsc.mil> References: <40B5D706.2050902@redhat.com> <1085663772.1072.149.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <40B5F324.9010208@redhat.com> Stephen Smalley wrote: >On Thu, 2004-05-27 at 07:54, Daniel J Walsh wrote: > > >>With the new design of the policy tree, we have moved the "contexts" >>files into >>/etc/selinux/*/contexts/ >> >>These files include default_contexts, file_contexts, default_type, >>failsafe_contexts ... >>as well as contexts for individual users like users/root. Currently the >>security contexts for these files is etc_t. Should we change them so >>something else? default_contexts_t? Should file_contexts be marked >>differently then the others? >> >> > >I'd suggest a single type (other than etc_t) for default_contexts, >default_type, failsafe_context, and the other files installed from >policy/appconfig. file_contexts should likely have a different type to >allow different access, so perhaps it should have its own directory and >type. With the old layout and policy, it ends up in policy_config_t, >but I think we want to distinguish it from the binary policy file as >well as from the appconfig files. > > > Ok how about, default_contexts_t for contexts directory and users directory. Create a new directory called files and put file_contexts in there with a context of file_contexts_t. >>Also since policy is determined by /etc/sysconfig/selinux, should we set >>a special security context on it? If we do should we move it to a >>directory where it would be easier to maintain the security context? >>Maybe rename it to /etc/selinux/config? >> >> > >I would prefer having a distinct type on it (and moving it to a >directory with that type so that we can easily preserve the type), as >the integrity of that file is critical to SELinux, at least in the >Fedora Core implementation. > > > Should that have default_contexts_t also? Or something different? From sds at epoch.ncsc.mil Thu May 27 14:27:21 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 27 May 2004 10:27:21 -0400 Subject: Security contexts for the contexts directory? In-Reply-To: <40B5F324.9010208@redhat.com> References: <40B5D706.2050902@redhat.com> <1085663772.1072.149.camel@moss-spartans.epoch.ncsc.mil> <40B5F324.9010208@redhat.com> Message-ID: <1085668041.1072.186.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-05-27 at 09:54, Daniel J Walsh wrote: > Ok how about, default_contexts_t for contexts directory and users > directory. Create a new directory called files and put file_contexts in > there with a context of file_contexts_t. The existing default_context_t (no 's') type seems reasonable for the contexts directory and users subdirectory. Note however that this will likely require new allow rules in the policy, as some domains may have previously had read access to the files under etc_t and will now need read permission to default_context_t. > Should that have default_contexts_t also? Or something different? /etc/selinux/config should have a different type. We could define a type for the /etc/selinux directory and simply use that type for the config file as well to ease maintenance. That would also make sense from a control perspective - you are unlikely to be allowed to modify the /etc/selinux directory (e.g. add new policies under it) unless you can also modify /etc/selinux/config to set the type. No other files under /etc/selinux would normally have that type, as everything else is a subdirectory and has a separate type assigned. -- Stephen Smalley National Security Agency From fritz.elfert at millenux.com Thu May 27 15:55:05 2004 From: fritz.elfert at millenux.com (Fritz Elfert) Date: Thu, 27 May 2004 17:55:05 +0200 (CEST) Subject: crond and /usr/bin/run-parts Message-ID: Hi, On FC2, the system housekeeping is executed as root via a shell script /usr/bin/run-parts which in turn executes scripts in /etc/cron.{hourly,daily,monthly}. This does not work in enforcing mode. Instead i get the following error: audit(1085671860.593:0): avc: denied { transition } for pid=17894 exe=/usr/sbin/crond path=/bin/bash dev=hda2 ino=883049 scontext=root:system_r:crond_t tcontext=user_u:sysadm_r:sysadm_t tclass=process If i interpret this correctly, crond is unable to change the execution context to root when trying to run /usr/bin/run-parts. I already submitted a bug-report for that (http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124533) but until it is fixed, i wanted to make my own workaround. I tried the following: In /etc/security/selinux/src/policy/file_contexts/misc/local.fc i have: /usr/bin/run-parts -- system_u:object_r:runparts_exec_t In /etc/security/selinux/src/policy/domains/misc/local.te i have: type runparts_exec_t, file_type, sysadmfile, exec_type; domain_trans(crond_t, shell_exec_t, sysadm_t) domain_trans(crond_t, runparts_exec_t, sysadm_t) I tried also adding: system_crond_entry(runparts_exec_t, sysadm_t) After relabeling and make reload, i still get this error. At least the script seems to be labeled ok: -rwxr-xr-x+ root root system_u:object_r:runparts_exec_t /usr/bin/run-parts What am i doing wrong? Thanks -Fritz -- Fritz Elfert Millenux GmbH Lilienthalstr. 2 Phone: +49 711 88770 400 70825 Stuttgart FAX: +49 711 88770 449 -------------------------------------------------------------------------- From parklee_fcsel at yahoo.com Thu May 27 16:38:22 2004 From: parklee_fcsel at yahoo.com (park lee) Date: Thu, 27 May 2004 09:38:22 -0700 (PDT) Subject: How to make SELinux in Fedora work? In-Reply-To: <1085660163.1072.84.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20040527163822.57288.qmail@web90102.mail.scd.yahoo.com> Dear sir, Thank you very much! I think I've learned a lot with you help. there are some other questions: What is the version of the Fedora Core 2 SELinux? When an updated public release of SELinux was made available on http://www.nsa.gov/selinux/, how can I do to also updated the Fedora Core 2 SELinux? Thanks again. Yours, Park Lee 2004-05-27 --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger -------------- next part -------------- An HTML attachment was scrubbed... URL: From bobgus at rcn.com Thu May 27 16:59:24 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Thu, 27 May 2004 11:59:24 -0500 Subject: Script to check security? Message-ID: With all of the possible variations in security settings - strict, permissive, local, lots of users, only daemons, etc. Is there a script around somewhere - something like 'configure' which is used at the beginning of a component build - which will query various pieces of a system, do a 'setenforce 1' and then try various programs and grep the output to give some binary answer, then do 'setenforce 0' and try the same program, etc. This script would help to give struggling sysadmins some degree of confidence that what is being done to their 'policy.local' or whatever, is benign. Of course the script could be corrupted or buggy - one more thing to add to when adding or changing the SELinux system, but there would be advantages: Just as the 'no child left behind' program uses testing to measure the effectiveness of public expenditures on schools ( :-) ), a security testing script could help to test the effectiveness of the SELinux system as it evolves. A testing script would also help to rein in the tendency to add wrinkles and grow the complexity of the system - each wrinkle would have a test module to check it. BobG From sds at epoch.ncsc.mil Thu May 27 17:32:36 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 27 May 2004 13:32:36 -0400 Subject: crond and /usr/bin/run-parts In-Reply-To: References: Message-ID: <1085679156.1072.245.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-05-27 at 11:55, Fritz Elfert wrote: > audit(1085671860.593:0): avc: denied { transition } for pid=17894 > exe=/usr/sbin/crond path=/bin/bash dev=hda2 ino=883049 > scontext=root:system_r:crond_t tcontext=user_u:sysadm_r:sysadm_t > tclass=process Try: /etc/init.d/crond stop runcon system_u:system_r:crond_t /usr/sbin/crond -- Stephen Smalley National Security Agency From Valdis.Kletnieks at vt.edu Thu May 27 18:00:53 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 27 May 2004 14:00:53 -0400 Subject: Script to check security? In-Reply-To: Your message of "Thu, 27 May 2004 11:59:24 CDT." References: Message-ID: <200405271800.i4RI0rbH011087@turing-police.cc.vt.edu> On Thu, 27 May 2004 11:59:24 CDT, Bob Gustafson said: > Is there a script around somewhere - something like 'configure' which is > used at the beginning of a component build - which will query various > pieces of a system, do a 'setenforce 1' and then try various programs and > grep the output to give some binary answer, then do 'setenforce 0' and try > the same program, etc. "Testing can reveal the presence of flaws, but not their absence" -- Dykstra Writing such a test harness for a program is a daunting challenge - the biggest hurdle is that although you can cover 75% of the issues simply by doing a 'setenforce 1' and seeing if the program will even start up, devising harness cases for the other 25% is very difficult - it's often stuff like "initial one-time file creation" or "error handling (I've had the joy of trying to debug an application that got a permission error while trying to open an error message catalog to get the human-readable form of "permission error" - instant recursive error ;) My posting about mysql the other day was related to another project of mine that involves a multi-gigabyte mysql database. The as-shipped mysql.fc labels files with the assumption that /var/lib/mysql/ is where the database lives. Now, either I get to live with a 40-gigabyte /var, or I also stick a mysqld_db_t on the /datastore/ tree where the database actually resides. Now for those of you listening at home - devise a test that will catch the difference between these two lines: /datastore/mydata(/.*)? system_u:object_r:mysqld_db_t /datastore(/.*)? system_u:object_r:mysqld_db_t (Hint - what happens if there's a /datastore/otherstuff directory?) > This script would help to give struggling sysadmins some degree of > confidence that what is being done to their 'policy.local' or whatever, is > benign. It's feasible to set up a script that verifies that a given program is given "enough" access - see 'audit2allow'. It's another challenge entirely to verify that it is in fact the minimal set of required access - mostly because it has no way to identify what "proper" means. (Hmm... I'm trying to figure out if the generic case of computing "minimal set" is the equivalent of the Halting Problem. It's actually probably fairly doable with static code analysis, except that programmers have this very annoying tendency to do stuff like call sprintf(foo,"%s", user_file); and then open(foo)... And sometimes they actually *want* a "../.." pattern in foo. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From fritz.elfert at millenux.com Thu May 27 18:00:43 2004 From: fritz.elfert at millenux.com (Fritz Elfert) Date: Thu, 27 May 2004 20:00:43 +0200 (CEST) Subject: crond and /usr/bin/run-parts In-Reply-To: <1085679156.1072.245.camel@moss-spartans.epoch.ncsc.mil> Message-ID: Thanks a lot, that did the trick. -Fritz On Thu, 27 May 2004, Stephen Smalley wrote: > On Thu, 2004-05-27 at 11:55, Fritz Elfert wrote: > > audit(1085671860.593:0): avc: denied { transition } for pid=17894 > > exe=/usr/sbin/crond path=/bin/bash dev=hda2 ino=883049 > > scontext=root:system_r:crond_t tcontext=user_u:sysadm_r:sysadm_t > > tclass=process > > Try: > /etc/init.d/crond stop > runcon system_u:system_r:crond_t /usr/sbin/crond > > -- Fritz Elfert Millenux GmbH Lilienthalstr. 2 Phone: +49 711 88770 400 70825 Stuttgart FAX: +49 711 88770 449 -------------------------------------------------------------------------- From selinux at comcast.net Thu May 27 18:07:33 2004 From: selinux at comcast.net (Tom London) Date: Thu, 27 May 2004 11:07:33 -0700 Subject: Enabling SELinux (was Re: How to make SELinux in Fedora work?) Message-ID: <40B62E65.8030005@comcast.net> I decided to give this a try on a FC2 machine that was installed with 'everything' but without enabling 'selinux' on the install. It had policy-1.11.3-3 (and policy-sources) installed. Following the attached advice, here's what I did: 1. Modified /etc/sysconfig/selinux to have 'SELINUX=permissive' 2. Rebooted single-user and ran 'fixfiles relabel' 3. Rebooted multi-user The machine booted up in permissive mode fine, with only a few 'avc' messages to examine. There were a couple of quickly noticed issues: 1. The 'swapon' command in the boot sequence failed: swapon: /dev/hda3: Invalid argument (entry from /var/log/messages: May 27 10:15:54 fedora kernel: Unable to find swap-space signature) I ran 'mkswap /dev/hda3; swapon -a' and all worked: May 27 10:17:47 fedora kernel: Adding 1502068k swap on /dev/hda3. Priority:-1 extents:1 2. Sound no longer worked, but I could find no obvious avc or other messages. (No sound from gain, xine, ...) I ran 'System Settings->Soundcard Detection', clicked OK in the popup, but nothing appeared to happen (also, no messages in /var/log/messages). BUT, sound started working, at least I can now hear music from 'xine'. After fixing the above, I set 'setenforce 1' and all appeared working well. I then edited /etc/sysconfig/selinux, changing 'SELINUX=permissive' to 'SELINUX=enforcing', and rebooted. Swap now got added correctly, and the system came up as expected. Even mozilla, including the added plugins worked! (This is quite impressive!!!!!) Sound didn't work again. I tried as normal user: 1. cd /usr/share/sounds aplay warning.wav Playing WAVE 'warning.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono But no sound. 2. play warning.wav Got sound! 3. aplay warning.wav Playing WAVE 'warning.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono Got Sound! I see nothing in /var/log/messages about this... Anyway, this exercise got me to convert this machine to SELinux/enforcing ( :-D ) Any thoughts on what happened to swap? Something I did? tom ------------------------------------------------------------------------ * /From/: Stephen Smalley * /To/: "Fedora SELinux support list for users & developers." * /Subject/: Re: How to make SELinux in Fedora work? * /Date/: Thu, 27 May 2004 08:16:03 -0400 ------------------------------------------------------------------------ On Thu, 2004-05-27 at 02:44, park lee wrote: > I've downloaded Fedora Core 2 from http://fedora.redhat.com/download/, > and have installed it successfully. As noted in the release notes for FC2 (http://fedora.redhat.com/docs/release-notes/), you have to pass "selinux" to the installer to enable SELinux at install time. > Then , I want to ask how to run SELinux which is integrated into > Fedora Core? Is there some resources about what to do and how to do ? If you didn't enable SELinux at install time, then you'll need to install a policy (yum install policy policy-sources), create or edit /etc/sysconfig/selinux and set SELINUX=permissive in it, and relabel your filesystems (via fixfiles relabel). Once you get your filesystems labeled and have verified that you can boot without avc denials in your logs, you can set SELINUX=enforcing in /etc/sysconfig/selinux. > And Is there any differences between it and the SELinux from > http://www.nsa.gov/selinux/code/download5.cfm. As i know ,when we want > to run the SELinux from > ttp://www.nsa.gov/selinux/code/download5.cfm.we should first recompile > the kernel with certain options, then install some applications (such > as checkpolicy, libselinux) from the SELinux Full Userland Archive to > the system. Then , if we want to run the SELinux that is integrated > into Fedora Core, should we do the same steps? Fedora Core 2 already includes the SELinux code in the kernel and applications, so you don't have to recompile anything. You just need to enable the SELinux support that is already there. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Thu May 27 18:11:04 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 27 May 2004 14:11:04 -0400 Subject: crond and /usr/bin/run-parts In-Reply-To: References: Message-ID: <1085681463.1072.265.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-05-27 at 14:00, Fritz Elfert wrote: > Thanks a lot, that did the trick. Good. I think we have to make a change to policy/constraints in the policy sources to avoid the problem in the future, as the crond process will revert to root:system_r:crond_t if you restart it by hand again without using runcon or run_init. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Thu May 27 18:18:08 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 27 May 2004 14:18:08 -0400 Subject: Enabling SELinux (was Re: How to make SELinux in Fedora work?) In-Reply-To: <40B62E65.8030005@comcast.net> References: <40B62E65.8030005@comcast.net> Message-ID: <1085681888.1072.269.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-05-27 at 14:07, Tom London wrote: > I see nothing in /var/log/messages about this... Did you try enabling all auditing? See http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/index.html#id3354612 > Any thoughts on what happened to swap? Something I did? I have no idea. -- Stephen Smalley National Security Agency From fritz.elfert at millenux.com Thu May 27 18:54:59 2004 From: fritz.elfert at millenux.com (Fritz Elfert) Date: Thu, 27 May 2004 20:54:59 +0200 (CEST) Subject: crond and /usr/bin/run-parts In-Reply-To: <1085681463.1072.265.camel@moss-spartans.epoch.ncsc.mil> Message-ID: After you mentioned run_init, i read it's manpage and tried "run_init service crond restart". Didn't work out of the box, but that was an easy one. Just added the following into my local.te: allow run_init_t sbin_t:file { read execute }; Now i can manually restart services properly with "run_init service whatever restart". Probably, /sbin/service should get a dedicated attribute instead of just system_u:object_r:sbin_t. Then one could have a more tighten rule describing what run_init_t is allowd to execute. Ciao -Fritz On Thu, 27 May 2004, Stephen Smalley wrote: > On Thu, 2004-05-27 at 14:00, Fritz Elfert wrote: > > Thanks a lot, that did the trick. > > Good. I think we have to make a change to policy/constraints in the > policy sources to avoid the problem in the future, as the crond process > will revert to root:system_r:crond_t if you restart it by hand again > without using runcon or run_init. > > -- Fritz Elfert Millenux GmbH Lilienthalstr. 2 Phone: +49 711 88770 400 70825 Stuttgart FAX: +49 711 88770 449 -------------------------------------------------------------------------- From selinux at comcast.net Thu May 27 19:32:01 2004 From: selinux at comcast.net (Tom London) Date: Thu, 27 May 2004 12:32:01 -0700 Subject: Enabling SELinux (was Re: How to make SELinux in Fedora work?) Message-ID: <40B64231.1040506@comcast.net> Sort of interesting..... I enabled all auditing as described, but still see no avc messages. I've localized it a bit: seems that play, aplay (alsa) works, but esdplay does not. I can't seem to start the esd daemon: ALSA lib pcm_hw.c:1056:(snd_pcm_hw_open) open /dev/snd/pcmC0D0p failed: Device or resource busy. I can work around this. (not certain this is an SELinux issue.....) Will SELinux 'conversions' like this be supported for FC3? If so, it will require a lot of testing.... tom ------------------------------------------------------------------------ * /From/: Stephen Smalley * /To/: "Fedora SELinux support list for users & developers." * /Subject/: Re: Enabling SELinux (was Re: How to make SELinux in Fedora work?) * /Date/: Thu, 27 May 2004 14:18:08 -0400 ------------------------------------------------------------------------ On Thu, 2004-05-27 at 14:07, Tom London wrote: > I see nothing in /var/log/messages about this... Did you try enabling all auditing? See http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/index.html#id3354612 > Any thoughts on what happened to swap? Something I did? I have no idea. -- Stephen Smalley National Security Agency From selinux at comcast.net Fri May 28 02:36:13 2004 From: selinux at comcast.net (Tom London) Date: Thu, 27 May 2004 19:36:13 -0700 Subject: Enabling SELinux (was Re: How to make SELinux in Fedora work?) Message-ID: <40B6A59D.8060602@comcast.net> OK. I tracked things down a bit. The swap problem is spurious (i.e. not related to SELinux). (My swap space got trashed a few days ago and I didn't notice.) Sorry to confuse matters..... I'm tracking down 'vestigial' files that were not assigned contexts by fixfiles. There were some in /var/tmp (kdecache-tbl, e.g.), etc. tom ------------------------------------------------------------------------ * /From/: Stephen Smalley * /To/: "Fedora SELinux support list for users & developers." * /Subject/: Re: Enabling SELinux (was Re: How to make SELinux in Fedora work?) * /Date/: Thu, 27 May 2004 14:18:08 -0400 ------------------------------------------------------------------------ On Thu, 2004-05-27 at 14:07, Tom London wrote: > I see nothing in /var/log/messages about this... Did you try enabling all auditing? See http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/index.html#id3354612 > Any thoughts on what happened to swap? Something I did? I have no idea. -- Stephen Smalley National Security Agency From matthew.east at iue.it Fri May 28 08:49:59 2004 From: matthew.east at iue.it (Matthew East) Date: Fri, 28 May 2004 10:49:59 +0200 Subject: Permission denied when building kernel In-Reply-To: <1085661919.1072.115.camel@moss-spartans.epoch.ncsc.mil> References: <1085612449.1965.1.camel@localhost> <1085661919.1072.115.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1085734199.1784.15.camel@localhost> On Thu, 2004-05-27 at 14:45, Stephen Smalley wrote: > On Thu, 2004-05-27 at 04:39, Matthew East wrote: > > I cannot build and install a kernel with selinux enabled. Here is what > > happens towards the end of the modules_install stage: > > > if [ -r System.map ]; then /sbin/depmod -ae -F System.map -b > > /var/tmp/kernel-2.6.6-root -r 2.6.6; fi > > WARNING: Couldn't open directory > > /var/tmp/kernel-2.6.6-root/lib/modules/2.6.6: Permission denied > > FATAL: Could not open > > /var/tmp/kernel-2.6.6-root/lib/modules/2.6.6/modules.dep.temp for > > writing: Permission denied > > make[1]: *** [_modinst_post] Error 1 > > error: Bad exit status from /var/tmp/rpm-tmp.11877 (%install) > > Add 'tmp_domain(depmod)' to > /etc/security/selinux/src/policy/domains/program/modutils.te and do a > 'make load' in /etc/security/selinux/src/policy. yum install > policy-sources if you don't already have it. Ok will try this. > > p.s. Just for the record, or in case they are useful, here are the error > > messages I get when booting my new kernel which was compiled with > > selinux set to permissive. > > > > Freeing unused kernel memory: 160k freed > > security: 5 users, 7 roles, 1244 types, 1 bools > > security: 30 classes, 303377 rules > > SELinux: Completing initialization. > > SELinux: Setting up existing superblocks. > > SELinux: initialized (dev , type selinuxfs), uses genfs_contexts > > SELinux: initialized (dev hda2, type ext3), uses xattr > > audit(1085619351.268:0): avc: denied { ioctl } for pid=164 > > exe=/bin/bash path=/dev/null dev=hda2 ino=283937 > > scontext=system_u:system_r:kernel_t > > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > > audit(1085619351.271:0): avc: denied { getattr } for pid=176 > > exe=/bin/bash path=/etc/hotplug dev=hda2 ino=49185 > > scontext=system_u:system_r:kernel_t > > tcontext=system_u:object_r:unlabeled_t tclass=dir > > Very odd; these certainly shouldn't be unlabeled_t. What does a > getfilecon /etc/hotplug (or any of these files that are showing up with > unlabeled_t) show? I'm afraid I've removed the custom kernel so I can't tell you. I assumed that the reason was that I'd compiled and installed the kernel with selinux as permissive. In any case, under my current setup with the fedora default kernel: [matt at localhost matt]$ getfilecon /etc/hotplug /etc/hotplug system_u:object_r:hotplug_etc_t To be honest my system is a bit strange at the moment, and I've put selinux back in permissive mode, as I keep finding strange things that I can't do with it in enforcing mode with no error messages (e.g. Openoffice.org doesn't open and I can't do a "glxgears" - weird huh?!) So it's probably that I've done something wrong. The installation of fedora was of test 2 and I've been updating it until Core 2. So maybe a clean install would be a good idea. Thanks very much for all your help. From bleher at informatik.uni-muenchen.de Fri May 28 10:58:54 2004 From: bleher at informatik.uni-muenchen.de (Thomas Bleher) Date: Fri, 28 May 2004 12:58:54 +0200 Subject: Permission denied when building kernel In-Reply-To: <1085661919.1072.115.camel@moss-spartans.epoch.ncsc.mil> References: <1085612449.1965.1.camel@localhost> <1085661919.1072.115.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20040528105854.GA2031@jmh.mhn.de> * Stephen Smalley [2004-05-27 14:45]: > On Thu, 2004-05-27 at 04:39, Matthew East wrote: > > p.s. Just for the record, or in case they are useful, here are the error > > messages I get when booting my new kernel which was compiled with > > selinux set to permissive. > > > > Freeing unused kernel memory: 160k freed > > security: 5 users, 7 roles, 1244 types, 1 bools > > security: 30 classes, 303377 rules > > SELinux: Completing initialization. > > SELinux: Setting up existing superblocks. > > SELinux: initialized (dev , type selinuxfs), uses genfs_contexts > > SELinux: initialized (dev hda2, type ext3), uses xattr > > audit(1085619351.268:0): avc: denied { ioctl } for pid=164 > > exe=/bin/bash path=/dev/null dev=hda2 ino=283937 > > scontext=system_u:system_r:kernel_t > > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > > audit(1085619351.271:0): avc: denied { getattr } for pid=176 > > exe=/bin/bash path=/etc/hotplug dev=hda2 ino=49185 > > scontext=system_u:system_r:kernel_t > > tcontext=system_u:object_r:unlabeled_t tclass=dir > > Very odd; these certainly shouldn't be unlabeled_t. What does a > getfilecon /etc/hotplug (or any of these files that are showing up with > unlabeled_t) show? It looks like it is a similar problem like the one that has bitten me[0]. Matthew said he had built a custom kernel so it is possible that a an unusual combination of kernel options is causing this. I am attaching my kernel .config (run through egrep -v '^#') so that hopefully someone with more kernel knowledge can debug this and find the problem. (I would be happy to test kernel patches trying to fix this) Thanks, Thomas [0]: see http://marc.theaimsgroup.com/?l=selinux&m=108535024629852&w=2 -- http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA D09E C562 2BAE B2F4 ABE7 -------------- next part -------------- CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_STANDALONE=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_LOG_BUF_SHIFT=15 CONFIG_HOTPLUG=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_KALLSYMS=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_X86_PC=y CONFIG_MPENTIUMIII=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_SMP=y CONFIG_NR_CPUS=8 CONFIG_PREEMPT=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y CONFIG_HIGHMEM4G=y CONFIG_HIGHMEM=y CONFIG_MTRR=y CONFIG_IRQBALANCE=y CONFIG_HAVE_DEC_LOCK=y CONFIG_PM=y CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_TABLE=y CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_POWERNOW_K6=y CONFIG_X86_POWERNOW_K8=y CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y CONFIG_X86_SPEEDSTEP_SMI=y CONFIG_X86_P4_CLOCKMOD=y CONFIG_X86_SPEEDSTEP_LIB=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y CONFIG_ISA=y CONFIG_PCMCIA_PROBE=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_MISC=y CONFIG_FW_LOADER=m CONFIG_PNP=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_LBD=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECD=y CONFIG_IDE_TASKFILE_IO=y CONFIG_IDE_GENERIC=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_GENERIC=y CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_ADMA=y CONFIG_BLK_DEV_AMD74XX=y CONFIG_BLK_DEV_CMD64X=y CONFIG_BLK_DEV_PIIX=y CONFIG_BLK_DEV_PDC202XX_OLD=m CONFIG_BLK_DEV_PDC202XX_NEW=m CONFIG_BLK_DEV_VIA82CXXX=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=y CONFIG_SCSI_REPORT_LUNS=y CONFIG_SCSI_SPI_ATTRS=y CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=32 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 CONFIG_AIC7XXX_DEBUG_ENABLE=y CONFIG_AIC7XXX_DEBUG_MASK=0 CONFIG_AIC7XXX_REG_PRETTY_PRINT=y CONFIG_SCSI_SATA=y CONFIG_SCSI_ATA_PIIX=y CONFIG_SCSI_SATA_PROMISE=y CONFIG_SCSI_SATA_VIA=y CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 CONFIG_SCSI_QLA2XXX=y CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID5=y CONFIG_MD_RAID6=y CONFIG_MD_MULTIPATH=y CONFIG_IEEE1394=y CONFIG_IEEE1394_OHCI1394=y CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_SBP2=m CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=m CONFIG_IEEE1394_CMP=m CONFIG_IEEE1394_AMDTP=m CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IPV6=y CONFIG_IPV6_PRIVACY=y CONFIG_INET6_AH=y CONFIG_INET6_ESP=y CONFIG_INET6_IPCOMP=y CONFIG_IPV6_TUNNEL=y CONFIG_NETFILTER=y CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y CONFIG_IP_NF_QUEUE=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y CONFIG_IP_NF_MATCH_IPRANGE=y CONFIG_IP_NF_MATCH_MAC=y CONFIG_IP_NF_MATCH_PKTTYPE=y CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_RECENT=y CONFIG_IP_NF_MATCH_ECN=y CONFIG_IP_NF_MATCH_DSCP=y CONFIG_IP_NF_MATCH_AH_ESP=y CONFIG_IP_NF_MATCH_LENGTH=y CONFIG_IP_NF_MATCH_TTL=y CONFIG_IP_NF_MATCH_TCPMSS=y CONFIG_IP_NF_MATCH_HELPER=y CONFIG_IP_NF_MATCH_STATE=y CONFIG_IP_NF_MATCH_CONNTRACK=y CONFIG_IP_NF_MATCH_OWNER=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_REDIRECT=y CONFIG_IP_NF_TARGET_NETMAP=y CONFIG_IP_NF_TARGET_SAME=y CONFIG_IP_NF_NAT_FTP=y CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=y CONFIG_IP_NF_TARGET_ECN=y CONFIG_IP_NF_TARGET_DSCP=y CONFIG_IP_NF_TARGET_MARK=y CONFIG_IP_NF_TARGET_CLASSIFY=y CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_TARGET_ULOG=y CONFIG_IP_NF_TARGET_TCPMSS=y CONFIG_IP_NF_ARPTABLES=y CONFIG_IP_NF_ARPFILTER=y CONFIG_IP_NF_ARP_MANGLE=y CONFIG_IP6_NF_QUEUE=y CONFIG_IP6_NF_IPTABLES=y CONFIG_IP6_NF_MATCH_LIMIT=y CONFIG_IP6_NF_MATCH_MAC=y CONFIG_IP6_NF_MATCH_RT=y CONFIG_IP6_NF_MATCH_OPTS=y CONFIG_IP6_NF_MATCH_FRAG=y CONFIG_IP6_NF_MATCH_HL=y CONFIG_IP6_NF_MATCH_MULTIPORT=y CONFIG_IP6_NF_MATCH_OWNER=y CONFIG_IP6_NF_MATCH_MARK=y CONFIG_IP6_NF_MATCH_IPV6HEADER=y CONFIG_IP6_NF_MATCH_AHESP=y CONFIG_IP6_NF_MATCH_LENGTH=y CONFIG_IP6_NF_MATCH_EUI64=y CONFIG_IP6_NF_FILTER=y CONFIG_IP6_NF_TARGET_LOG=y CONFIG_IP6_NF_MANGLE=y CONFIG_IP6_NF_TARGET_MARK=y CONFIG_XFRM=y CONFIG_XFRM_USER=y CONFIG_NET_SCHED=y CONFIG_NET_SCH_HTB=y CONFIG_NET_SCH_TBF=y CONFIG_NET_QOS=y CONFIG_NET_CLS=y CONFIG_NET_CLS_FW=y CONFIG_NET_CLS_POLICE=y CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_HCIUSB=m CONFIG_BT_HCIUSB_SCO=y CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIUART_BCSP_TXCRC=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIVHCI=m CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_NET_ETHERNET=y CONFIG_MII=y CONFIG_NET_VENDOR_3COM=y CONFIG_EL3=y CONFIG_VORTEX=y CONFIG_TYPHOON=y CONFIG_NET_PCI=y CONFIG_E100=y CONFIG_8139TOO=y CONFIG_ACENIC=y CONFIG_E1000=y CONFIG_NS83820=y CONFIG_R8169=y CONFIG_TIGON3=y CONFIG_SHAPER=m CONFIG_INPUT=y CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_EVDEV=m CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_PCIPS2=m CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y CONFIG_KEYBOARD_XTKBD=m CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_CORE=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 CONFIG_RTC=y CONFIG_AGP=m CONFIG_AGP_AMD=m CONFIG_AGP_AMD64=m CONFIG_AGP_INTEL=m CONFIG_AGP_NVIDIA=m CONFIG_AGP_VIA=m CONFIG_DRM=y CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m CONFIG_DRM_I810=m CONFIG_DRM_I830=m CONFIG_DRM_MGA=m CONFIG_I2C=m CONFIG_I2C_CHARDEV=m CONFIG_I2C_ALGOBIT=m CONFIG_I2C_I810=m CONFIG_I2C_ISA=m CONFIG_I2C_NFORCE2=m CONFIG_I2C_PIIX4=m CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m CONFIG_VIDEO_DEV=m CONFIG_VIDEO_BT848=m CONFIG_VIDEO_PMS=m CONFIG_VIDEO_CPIA=m CONFIG_VIDEO_CPIA_USB=m CONFIG_VIDEO_SAA5249=m CONFIG_TUNER_3036=m CONFIG_VIDEO_STRADIS=m CONFIG_VIDEO_ZORAN=m CONFIG_VIDEO_ZORAN_BUZ=m CONFIG_VIDEO_ZORAN_DC10=m CONFIG_VIDEO_ZORAN_DC30=m CONFIG_VIDEO_ZORAN_LML33=m CONFIG_VIDEO_ZORAN_LML33R10=m CONFIG_VIDEO_SAA7134=m CONFIG_VIDEO_MXB=m CONFIG_VIDEO_DPC=m CONFIG_VIDEO_HEXIUM_ORION=m CONFIG_VIDEO_HEXIUM_GEMINI=m CONFIG_VIDEO_CX88=m CONFIG_VIDEO_SAA7146=m CONFIG_VIDEO_SAA7146_VV=m CONFIG_VIDEO_VIDEOBUF=m CONFIG_VIDEO_TUNER=m CONFIG_VIDEO_BUF=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_IR=m CONFIG_FB=y CONFIG_FB_VESA=y CONFIG_VIDEO_SELECT=y CONFIG_FB_I810=m CONFIG_FB_I810_GTF=y CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_PCI_CONSOLE=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_LOGO=y CONFIG_LOGO_LINUX_MONO=y CONFIG_LOGO_LINUX_VGA16=y CONFIG_LOGO_LINUX_CLUT224=y CONFIG_SOUND=y CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m CONFIG_SND_MPU401_UART=m CONFIG_SND_OPL3_LIB=m CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m CONFIG_SND_AD1848=m CONFIG_SND_SB16=m CONFIG_SND_AC97_CODEC=m CONFIG_SND_BT87X=m CONFIG_SND_EMU10K1=m CONFIG_SND_TRIDENT=m CONFIG_SND_YMFPCI=m CONFIG_SND_CMIPCI=m CONFIG_SND_ENS1370=m CONFIG_SND_ENS1371=m CONFIG_SND_MAESTRO3=m CONFIG_SND_FM801=m CONFIG_SND_INTEL8X0=m CONFIG_SND_VIA82XX=m CONFIG_USB=y CONFIG_USB_DEVICEFS=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_UHCI_HCD=y CONFIG_USB_PRINTER=y CONFIG_USB_STORAGE=y CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y CONFIG_USB_WACOM=m CONFIG_USB_DABUSB=m CONFIG_USB_IBMCAM=m CONFIG_USB_KONICAWC=m CONFIG_USB_OV511=m CONFIG_USB_SE401=m CONFIG_USB_STV680=m CONFIG_USB_W9968CF=m CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_JBD=y CONFIG_FS_MBCACHE=y CONFIG_FS_POSIX_ACL=y CONFIG_MINIX_FS=m CONFIG_ROMFS_FS=m CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=y CONFIG_UDF_FS=y CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_NTFS_FS=y CONFIG_NTFS_RW=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y CONFIG_DEVPTS_FS_XATTR=y CONFIG_DEVPTS_FS_SECURITY=y CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_HFSPLUS_FS=m CONFIG_CRAMFS=m CONFIG_VXFS_FS=m CONFIG_HPFS_FS=m CONFIG_QNX4FS_FS=m CONFIG_SYSV_FS=m CONFIG_UFS_FS=m CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V4=y CONFIG_ROOT_NFS=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_SUNRPC=y CONFIG_SUNRPC_GSS=y CONFIG_RPCSEC_GSS_KRB5=y CONFIG_SMB_FS=m CONFIG_SMB_NLS_DEFAULT=y CONFIG_SMB_NLS_REMOTE="cp437" CONFIG_CIFS=m CONFIG_PARTITION_ADVANCED=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y CONFIG_LDM_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_ISO8859_15=y CONFIG_NLS_UTF8=y CONFIG_PROFILING=y CONFIG_OPROFILE=y CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_SPINLOCK_SLEEP=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_CAPABILITIES=m CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_MD4=y CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_DES=y CONFIG_CRYPTO_BLOWFISH=y CONFIG_CRYPTO_TWOFISH=y CONFIG_CRYPTO_SERPENT=y CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_CAST5=y CONFIG_CRYPTO_CAST6=y CONFIG_CRYPTO_ARC4=y CONFIG_CRYPTO_DEFLATE=y CONFIG_CRC32=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_X86_STD_RESOURCES=y CONFIG_PC=y -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From Valdis.Kletnieks at vt.edu Fri May 28 14:27:02 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 28 May 2004 10:27:02 -0400 Subject: Permission denied when building kernel In-Reply-To: Your message of "Fri, 28 May 2004 12:58:54 +0200." <20040528105854.GA2031@jmh.mhn.de> References: <1085612449.1965.1.camel@localhost> <1085661919.1072.115.camel@moss-spartans.epoch.ncsc.mil> <20040528105854.GA2031@jmh.mhn.de> Message-ID: <200405281427.i4SER2MB000599@turing-police.cc.vt.edu> (Attribution lost, sorry...) > > Very odd; these certainly shouldn't be unlabeled_t. What does a > > getfilecon /etc/hotplug (or any of these files that are showing up with > > unlabeled_t) show? I've managed to have this happen two different ways: 1) /tmp was on a tmpfs filesystem, so got wiped every reboot. 2) I managed to get 'udev' to fail to label stuff as well, but I can't remember how that one happened.. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From bobgus at rcn.com Fri May 28 16:51:38 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Fri, 28 May 2004 11:51:38 -0500 Subject: Script to check security? In-Reply-To: <200405271800.i4RI0rbH011087@turing-police.cc.vt.edu> References: Your message of "Thu, 27 May 2004 11:59:24 CDT." Message-ID: On Thu, 27 May 2004 14:00:53 -0400, Valdis.Kletnieks wrote: >On Thu, 27 May 2004 11:59:24 CDT, Bob Gustafson said: > >> Is there a script around somewhere - something like 'configure' which is >> used at the beginning of a component build - which will query various >> pieces of a system, do a 'setenforce 1' and then try various programs and >> grep the output to give some binary answer, then do 'setenforce 0' and try >> the same program, etc. > >"Testing can reveal the presence of flaws, but not their absence" -- Dykstra > >Writing such a test harness for a program is a daunting challenge - the >biggest >hurdle is that although you can cover 75% of the issues simply by doing a >'setenforce 1' and seeing if the program will even start up, devising harness >cases for the other 25% is very difficult - it's often stuff like "initial >one-time >file creation" or "error handling (I've had the joy of trying to debug an >application >that got a permission error while trying to open an error message catalog >to get >the human-readable form of "permission error" - instant recursive error ;) > >My posting about mysql the other day was related to another project of >mine that >involves a multi-gigabyte mysql database. The as-shipped mysql.fc labels >files >with the assumption that /var/lib/mysql/ is where the database lives. >Now, either I get to live with a 40-gigabyte /var, or I also stick a >mysqld_db_t >on the /datastore/ tree where the database actually resides. > >Now for those of you listening at home - devise a test that will catch the >difference between these two lines: > >/datastore/mydata(/.*)? system_u:object_r:mysqld_db_t >/datastore(/.*)? system_u:object_r:mysqld_db_t > >(Hint - what happens if there's a /datastore/otherstuff directory?) (I do need to read more of the FAQs and docs, but here is a stab..) Assuming that /datastore/mydata(/.*) is more restrictive than /datastore(/.*), the testing probe could be a small program that 'looks like' mysqld (assumes same roles with same selinux tags as mysqld) which tries to access files in the 'crack' between /datastore/mydata and /datastore. As part of the testing procedure, files could be dropped in the 'crack' for this test program to access. (File access could be generalized to cover shared memory access, sockets, etc.) Another wrinkle would be to add an error return code (or codes) to all of the OS file access routines which would tell a calling program that it was trying to open a file without sufficient SELinux permission (maybe this has been done already). This feature would help to make probes a bit more intelligent If probe programs were written in great numbers, the /var/log/messages file would be a large problem. Something would need to be done that would turn off logging during probe testing, or some such. This would have to be done carefully as it is would be a big door for hackers. With a good testing scheme, patterns would begin to emerge which could be used to simplify and regularize OS access needs. 'Simple' means that proof testing would have a better chance. > >> This script would help to give struggling sysadmins some degree of >> confidence that what is being done to their 'policy.local' or whatever, is >> benign. > >It's feasible to set up a script that verifies that a given program is given >"enough" access - see 'audit2allow'. It's another challenge entirely to >verify >that it is in fact the minimal set of required access - mostly because it has >no way to identify what "proper" means. > >(Hmm... I'm trying to figure out if the generic case of computing "minimal >set" >is the equivalent of the Halting Problem. It's actually probably fairly >doable >with static code analysis, except that programmers have this very annoying >tendency to do stuff like call sprintf(foo,"%s", user_file); and then >open(foo)... And sometimes they actually *want* a "../.." pattern in foo. ;) > From Valdis.Kletnieks at vt.edu Fri May 28 17:11:14 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 28 May 2004 13:11:14 -0400 Subject: Script to check security? In-Reply-To: Your message of "Fri, 28 May 2004 11:51:38 CDT." References: "Your message of Thu, 27 May 2004 11:59:24 CDT." Message-ID: <200405281711.i4SHBEJn024059@turing-police.cc.vt.edu> On Fri, 28 May 2004 11:51:38 CDT, Bob Gustafson said: > >/datastore/mydata(/.*)? system_u:object_r:mysqld_db_t > >/datastore(/.*)? system_u:object_r:mysqld_db_t > > > > (Hint - what happens if there's a /datastore/otherstuff directory?) > Assuming that /datastore/mydata(/.*) is more restrictive than > /datastore(/.*), the testing probe could be a small program that 'looks > like' mysqld (assumes same roles with same selinux tags as mysqld) which > tries to access files in the 'crack' between /datastore/mydata and > /datastore. As part of the testing procedure, files could be dropped in the > 'crack' for this test program to access. Yes. However, you just forgot to verify that SAS still works when accessing its datasets in /datastore/otherstuff because it's labeled mysql_db_t instead of whatever it should have been for SAS... Or maybe it wasn't SAS, but Mathematica. Or was it that other app??? (Yes, it was a trick question to make a point....) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From gene at czarc.net Fri May 28 17:53:23 2004 From: gene at czarc.net (Gene Czarcinski) Date: Fri, 28 May 2004 13:53:23 -0400 Subject: selinux and RHEL Message-ID: <200405281353.23244.gene@czarc.net> This may be a bit early but ... are there plans to incorporate selinux into Red Hat Enterprise Linux? If there is, is the target for RHEL 4 or later? Gene From wfrazee at wynweb.net Fri May 28 18:09:55 2004 From: wfrazee at wynweb.net (Wayne Frazee) Date: Fri, 28 May 2004 12:09:55 -0600 Subject: selinux and RHEL In-Reply-To: <200405281353.23244.gene@czarc.net> References: <200405281353.23244.gene@czarc.net> Message-ID: <1085767794.27696.66.camel@wfrazee.serveftp.com> This is just my own personal input on the matter but I would think that a determination on this matter by Red Hat this early in the game would be irresponsibly premature. At this point, the SELinux packages are note even integrated into mainstream Fedora due to the problems of creating a package and configuration tools for widespread implementation into a distribution. I would think that far more testing and fixing and tweaking needs done under the auspices of the Fedora Core testing environment before Red Hat can consider production implementation into the RHEL supported distributions. Further, I would like to make a suggestion. I dont know who here works with apache development but apache uses a periodic development summary that is essentially a "state of the package". I dont have a copy of a recent one at hand for the moment however it goes soemthing like this: Version 2.1.0 Showstopper Bugs This thing keeps breaking, blah, blah, blah. Not Showstopper but Would be good to Fix This Bug that Bug The other Bug Wish List Reorient that Feature to this Feature (IMPROVED!) A digest of this nature would be great for tracking status of the SELinux implementation in Fedora Core. What do you all think? -- -------------------- Wayne S. Frazee "Any sufficiently developed bug is indistinguishable from a feature." On Fri, 2004-05-28 at 11:53, Gene Czarcinski wrote: > This may be a bit early but ... are there plans to incorporate selinux into > Red Hat Enterprise Linux? If there is, is the target for RHEL 4 or later? > > Gene > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rhally at mindspring.com Fri May 28 18:20:11 2004 From: rhally at mindspring.com (Richard Hally) Date: Fri, 28 May 2004 14:20:11 -0400 Subject: installing new policies Message-ID: <40B782DB.9030800@mindspring.com> for what it's worth, I just tried installing the new selinux-policy-strict and -targeted and there is a dependency between setools and the old policy (and policy-source). It seems that we need updated rpms for setools and setools-gui. Richard Hally From rhallyx at mindspring.com Fri May 28 18:34:30 2004 From: rhallyx at mindspring.com (Richard Hally) Date: Fri, 28 May 2004 14:34:30 -0400 Subject: Installing the new policy Message-ID: <40B78636.2030009@mindspring.com> Included below is the out put from doing a "yum install selinux-policy\*" while in enforcing mode: [root at old1 root]# yum install selinux-policy\* Gathering header information file(s) from server(s) Server: Fedora Core 2 - i386 - Base Server: Fedora Core 2 - Development Tree Server: Fedora Core 2 - i386 - Released Updates Finding updated packages Downloading needed headers Resolving dependencies Dependencies resolved I will do the following: [install: selinux-policy-targeted 1.13.1-1.noarch] [install: selinux-policy-strict 1.13.1-1.noarch] [install: selinux-policy-strict-sources 1.13.1-1.noarch] [install: selinux-policy-targeted-sources 1.13.1-1.noarch] Is this ok [y/N]: y Downloading Packages Getting selinux-policy-targeted-1.13.1-1.noarch.rpm selinux-policy-targeted-1 100% |=========================| 25 kB 00:00 Getting selinux-policy-strict-1.13.1-1.noarch.rpm selinux-policy-strict-1.1 100% |=========================| 1.1 MB 00:08 Getting selinux-policy-strict-sources-1.13.1-1.noarch.rpm selinux-policy-strict-sou 100% |=========================| 1.3 MB 00:12 Getting selinux-policy-targeted-sources-1.13.1-1.noarch.rpm selinux-policy-targeted-s 100% |=========================| 252 kB 00:01 Running test transaction: Test transaction complete, Success! selinux-policy-strict 100 % done 1/6 Can't open '/etc/selinux/strict/policy/policy.17': Permission denied selinux-policy-targeted 100 % done 2/6 Can't open '/etc/selinux/targeted/policy/policy.17': Permission denied selinux-policy-strict-sources 100 % done 3/6 make: Entering directory `/etc/selinux/strict/src/policy' /usr/sbin/load_policy /etc/selinux/strict/policy/policy.`cat /selinux/policyvers` Can't open '/etc/selinux/strict/policy/policy.17': Permission denied make: *** [tmp/load] Error 2 make: Leaving directory `/etc/selinux/strict/src/policy' selinux-policy-targeted-sources 100 % done 4/6 make: Entering directory `/etc/selinux/targeted/src/policy' /usr/sbin/load_policy /etc/selinux/targeted/policy/policy.`cat /selinux/policyvers` Can't open '/etc/selinux/targeted/policy/policy.17': Permission denied make: *** [tmp/load] Error 2 make: Leaving directory `/etc/selinux/targeted/src/policy' warning: /etc/security/selinux/policy.17 saved as /etc/security/selinux/policy.17.rpmsave warning: /etc/security/selinux/file_contexts saved as /etc/security/selinux/file_contexts.rpmsave Erasing: policy 5/6 warning: /etc/security/selinux/src/policy/users saved as /etc/security/selinux/src/policy/users.rpmsave warning: /etc/security/selinux/src/policy/file_contexts/program/seuser.fc saved as /etc/security/selinux/src/policy/file_contexts/program/seuser.fc.rpmsave Erasing: policy-sources 6/6 Installed: selinux-policy-targeted 1.13.1-1.noarch selinux-policy-strict 1.13.1-1.noarch selinux-policy-strict-sources 1.13.1-1.noarch selinux-policy-targeted-sources 1.13.1-1.noarch Transaction(s) Complete [root at old1 root]# Richard Hally From dwalsh at redhat.com Fri May 28 18:33:33 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 28 May 2004 14:33:33 -0400 Subject: selinux and RHEL In-Reply-To: <200405281353.23244.gene@czarc.net> References: <200405281353.23244.gene@czarc.net> Message-ID: <40B785FD.8080708@redhat.com> Gene Czarcinski wrote: >This may be a bit early but ... are there plans to incorporate selinux into >Red Hat Enterprise Linux? If there is, is the target for RHEL 4 or later? > >Gene > > > The current plan is to add SELinux support to RHEL 4. Whether it is enabled or disabled and which policy to use are not certain yet. Dan >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From bobgus at rcn.com Sat May 29 01:14:15 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Fri, 28 May 2004 20:14:15 -0500 Subject: Script to check security? In-Reply-To: <200405281711.i4SHBEJn024059@turing-police.cc.vt.edu> References: Your message of "Fri, 28 May 2004 11:51:38 CDT." "Your message of Thu, 27 May 2004 11:59:24 CDT." Message-ID: On Fri, 28 May 2004 13:11:14 -0400, Valdis.Kletnieks at vt.edu wrote: >On Fri, 28 May 2004 11:51:38 CDT, Bob Gustafson said: >> >/datastore/mydata(/.*)? system_u:object_r:mysqld_db_t >> >/datastore(/.*)? system_u:object_r:mysqld_db_t >> > >> > (Hint - what happens if there's a /datastore/otherstuff directory?) > >> Assuming that /datastore/mydata(/.*) is more restrictive than >> /datastore(/.*), the testing probe could be a small program that 'looks >> like' mysqld (assumes same roles with same selinux tags as mysqld) which >> tries to access files in the 'crack' between /datastore/mydata and >> /datastore. As part of the testing procedure, files could be dropped in the >> 'crack' for this test program to access. > >Yes. However, you just forgot to verify that SAS still works when accessing >its datasets in /datastore/otherstuff because it's labeled mysql_db_t instead >of whatever it should have been for SAS... > >Or maybe it wasn't SAS, but Mathematica. Or was it that other app??? The 'test suite', just like the build tool 'configure', would be a collection of probes and test wrappers. SAS and Mathematica would also have their own modular piece of the test script (and have their files properly labeled). Perhaps these test script modules will converge to some common form which can be customized a bit for the 'next' application. Much of the GNU build process has evolved to mostly the same code for different applications - just a few names are changed at a higher level. The process of doing it, finding the problems, and then finding the commonality in the checks, and using the commonality to simplify the system is very important. SELinux is a whack at developing a useful language for this commonality. Using the policy to nudge the kernel development is the next step. (or maybe the step after next..) > >(Yes, it was a trick question to make a point....) Keep 'em coming. From parklee_fcsel at yahoo.com Sat May 29 02:26:08 2004 From: parklee_fcsel at yahoo.com (park lee) Date: Fri, 28 May 2004 19:26:08 -0700 (PDT) Subject: selinux and RHEL In-Reply-To: <200405281353.23244.gene@czarc.net> Message-ID: <20040529022608.1944.qmail@web90109.mail.scd.yahoo.com> Hi, There is a link for the issue: http://www.cryptonomicon.net/modules.php?name=News&file=article&sid=673. Park Lee --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger -------------- next part -------------- An HTML attachment was scrubbed... URL: From bobgus at rcn.com Sat May 29 19:49:41 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Sat, 29 May 2004 14:49:41 -0500 Subject: Installing the new policy In-Reply-To: <40B78636.2030009@mindspring.com> Message-ID: I am also having problems installing the new selinux stuff I wonder if the main problem is a missing /etc/selinux/config file which probably tells pieces of the system which of the policy-strict, etc. files to use (??) I updated my system and did a 'yum install policy\*` (maybe also selinux-policy\* too) - Also saw error messages (but also 'success') during yum run. [root at hoho2 user1]# date Sat May 29 14:33:39 CDT 2004 [root at hoho2 user1]# /sbin/fixfiles relabel /sbin/fixfiles: line 23: /etc/selinux/config: No such file or directory [root at hoho2 user1]# ls -l /etc/selinux total 16 drwxr-xr-x 5 root root 4096 May 29 12:05 strict drwxr-xr-x 5 root root 4096 May 29 12:06 targeted [root at hoho2 user1]# --- I am also getting a flock of console messages of the form: --- --- (I thought doing a 'fixfiles relabel' would clear these up, but.. -- inode_doinit_with_dentry: context_to_sid(user_u:object_r:user_tmp_t) returned 22 for dev=sda2 ino=6094897 inode_doinit_with_dentry: context_to_sid(user_u:object_r:user_tmp_t) returned 22 for dev=sda2 ino=6094944 inode_doinit_with_dentry: context_to_sid(user_u:object_r:user_tmp_t) returned 22 for dev=sda2 ino=6094946 inode_doinit_with_dentry: context_to_sid(user_u:object_r:user_tmp_t) returned 22 for dev=sda2 ino=6094908 ---- additional info --- [root at hoho2 user1]# od -c /selinux/enforce 0000000 0 0000001 [root at hoho2 user1]# [user1 at hoho2 user1]$ cat /proc/version Linux version 2.6.6-1.397smp (bhcompile at tweety.build.redhat.com) (gcc version 3. 3.3 20040412 (Red Hat Linux 3.3.3-7)) #1 SMP Fri May 28 11:34:11 EDT 2004 [user1 at hoho2 user1]$ [root at hoho2 selinux]# pwd /etc/security/selinux [root at hoho2 selinux]# ls -l total 51056 -rw-r--r-- 1 root root 86904 May 29 12:13 file_contexts -rw-r--r-- 1 root root 88310 May 11 10:03 file_contexts.rpmnew -rw-r--r-- 1 root root 87205 May 26 12:56 file_contexts.rpmsave -rw-r--r-- 1 root root 7408105 May 29 12:13 policy.15 -rw-r--r-- 1 root root 7383775 May 20 21:37 policy.15.rpmsave -rw-r--r-- 1 root root 7409842 May 29 12:13 policy.16 -rw-r--r-- 1 root root 7385512 May 20 21:37 policy.16.rpmsave -rw-r--r-- 1 root root 7410154 May 29 12:13 policy.17 -rw-r--r-- 1 root root 7409751 May 11 10:03 policy.17.rpmnew -rw-r--r-- 1 root root 7434273 May 26 12:56 policy.17.rpmsave drwx------ 3 root root 4096 May 7 10:24 src [root at hoho2 selinux]# BobG On Fri, 28 May 2004 14:34:30 -0400, Richard Hally wrote: >Included below is the out put from doing a "yum install >selinux-policy\*" while in enforcing mode: > >[root at old1 root]# yum install selinux-policy\* >Gathering header information file(s) from server(s) >Server: Fedora Core 2 - i386 - Base >Server: Fedora Core 2 - Development Tree >Server: Fedora Core 2 - i386 - Released Updates >Finding updated packages >Downloading needed headers >Resolving dependencies >Dependencies resolved >I will do the following: >[install: selinux-policy-targeted 1.13.1-1.noarch] >[install: selinux-policy-strict 1.13.1-1.noarch] >[install: selinux-policy-strict-sources 1.13.1-1.noarch] >[install: selinux-policy-targeted-sources 1.13.1-1.noarch] >Is this ok [y/N]: y >Downloading Packages >Getting selinux-policy-targeted-1.13.1-1.noarch.rpm >selinux-policy-targeted-1 100% |=========================| 25 kB 00:00 >Getting selinux-policy-strict-1.13.1-1.noarch.rpm >selinux-policy-strict-1.1 100% |=========================| 1.1 MB 00:08 >Getting selinux-policy-strict-sources-1.13.1-1.noarch.rpm >selinux-policy-strict-sou 100% |=========================| 1.3 MB 00:12 >Getting selinux-policy-targeted-sources-1.13.1-1.noarch.rpm >selinux-policy-targeted-s 100% |=========================| 252 kB 00:01 >Running test transaction: >Test transaction complete, Success! >selinux-policy-strict 100 % done 1/6 >Can't open '/etc/selinux/strict/policy/policy.17': Permission denied >selinux-policy-targeted 100 % done 2/6 >Can't open '/etc/selinux/targeted/policy/policy.17': Permission denied >selinux-policy-strict-sources 100 % done 3/6 >make: Entering directory `/etc/selinux/strict/src/policy' >/usr/sbin/load_policy /etc/selinux/strict/policy/policy.`cat >/selinux/policyvers` >Can't open '/etc/selinux/strict/policy/policy.17': Permission denied >make: *** [tmp/load] Error 2 >make: Leaving directory `/etc/selinux/strict/src/policy' >selinux-policy-targeted-sources 100 % done 4/6 >make: Entering directory `/etc/selinux/targeted/src/policy' >/usr/sbin/load_policy /etc/selinux/targeted/policy/policy.`cat >/selinux/policyvers` >Can't open '/etc/selinux/targeted/policy/policy.17': Permission denied >make: *** [tmp/load] Error 2 >make: Leaving directory `/etc/selinux/targeted/src/policy' >warning: /etc/security/selinux/policy.17 saved as >/etc/security/selinux/policy.17.rpmsave >warning: /etc/security/selinux/file_contexts saved as >/etc/security/selinux/file_contexts.rpmsave >Erasing: policy 5/6 >warning: /etc/security/selinux/src/policy/users saved as >/etc/security/selinux/src/policy/users.rpmsave >warning: >/etc/security/selinux/src/policy/file_contexts/program/seuser.fc saved >as /etc/security/selinux/src/policy/file_contexts/program/seuser.fc.rpmsave >Erasing: policy-sources 6/6 >Installed: selinux-policy-targeted 1.13.1-1.noarch >selinux-policy-strict 1.13.1-1.noarch selinux-policy-strict-sources >1.13.1-1.noarch selinux-policy-targeted-sources 1.13.1-1.noarch >Transaction(s) Complete >[root at old1 root]# > >Richard Hally >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list From selinux at comcast.net Sun May 30 00:37:04 2004 From: selinux at comcast.net (Tom London) Date: Sat, 29 May 2004 17:37:04 -0700 Subject: Installing the new policy Message-ID: <40B92CB0.5070205@comcast.net> I also had some issues in the newest selinux-policy installs from the development tree. First, I had to remove setools to remove a yum/rpm conflict. After successfully yum'ing selinux-policy-strict-sources (which also installed selinux-policy-strict and removed policy and policy-sources), I rebooted in single user mode, where I did the usual 'fixfiles relabel'. I then rebooted to multiuser mode, where I determined that the 'mode' was set to 'disabled' (i.e., 'getenforce->disabled'). Rooting around uncovered that there was no /etc/selinux/config installed, nor was /etc/sysconfig/selinux updated with the 'SELINUXTYPE=strict' line. Since the thread on this was confusing to me, I also added a line 'POLICYTYPE=strict'). I modified /etc/syconfig/selinux copied it to /etc/selinux/config and rebooted. Still came up with selinux in 'disabled' mode. Checking /var/log/messages showed 'SELinux disabled at boot'. So, I rebooted adding 'selinux=1' to the boot line. This time, the boot failed with 'can't read /etc/fstab' and brought me up in 'filesystem repair' mode. There I determined that /etc/fstab had no security context assigned to it (Did it get rewritten during a 'disabled' boot?) I rebooted without the 'selinux=1' but in single-user mode, where I adjusted the context of /etc/fstab, /etc/sysconfig/selinux and /etc/selinux/config. I also changed /etc/sysconfig/selinux to boot up in permissive mode. Rebooting with 'selinux=1 single' worked, I reran 'fixfiles relabel'. Rebooting with 'selinux=1' into permissive/multi-user worked. I changed /etc/sysconfig/selinux and /etc/selinux/config to 'enforce'. Rebooting single-user (i.e., with 'selinux=1 single') worked. Rebooting strict/multi-user (i.e. with 'selinux=1') did not work. It got jammed setting up X.org log files. Seems that /var/log/Xorg.0.log.old had no security context so the attempt to move /var/log/Xorg.0.log 'on top of it' failed. I'm guessing it was a leftover from a 'disabled' boot.) I fixed that ('chcon --reference Xorg.0.log Xorg.0.log.old'), fixed /tmp/gconfd-tbl (same problem), and now it boots up strict/multi-user. So here's the condensed version; 1. installing selinux-policy-strict-sources (and selinux-policy-strict) did not setup /etc/selinux/config, nor did it modify /etc/sysconfig/selinux. (I must admit that I was confused by the message thread. Did I need to remove /etc/sysconfig/selinux before doing the 'yum install selinux-policy-strict-sources'? I thought the install would add the 'SELINUXTYPE=strict' line to an existing file, but I may have read this wrong.) 2. My system was 'setup' to boot by default into 'disabled' mode. This caused a lot of problems with unlabeled files, directories, etc. Accidently forgetting to add 'selinux=1' to the boot line may cause this. 3. I had to 'yum remove setools'. Did this cause my booting or other problems? 4. I added both 'SELINUXTYPE=' and 'POLICYTYPE=' lines to /etc/sysconfig/selinux and to /etc/selinux/config. Are both needed/correct? /sbin/fixfiles seems to want 'SELINUXTYPE'... 5. I manually copied /etc/selinux/conf from /etc/sysconfig/selinux. Does that provide the correct info/format? System is up and running in strict/enforcing mode. I will later try to install selinux-policy-targeted*. tom From bobgus at rcn.com Sun May 30 05:38:17 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Sun, 30 May 2004 00:38:17 -0500 Subject: Installing the new policy - bravo In-Reply-To: <40B92CB0.5070205@comcast.net> Message-ID: Great, your receipe worked pretty well - (but I'm not quite up at enforcing=1) It is good to make the changes to /etc/security/selinux first. I made mine with the active lines: SELINUX=enforcing SELINUXTYPE=strict POLICYTYPE=strict Then I copied it over to /etc/selinux/config [root at hoho2 user1]# cd /etc/selinux [root at hoho2 selinux]# ls -l total 20 -rw-r--r-- 1 root root 332 May 29 23:47 config drwxr-xr-x 5 root root 4096 May 29 12:05 strict drwxr-xr-x 5 root root 4096 May 29 12:06 targeted [root at hoho2 selinux]# Adding the word 'single' to the grub.conf kernel line was a timesaver, and potentially avoided more problems. I think I was running for awhile with the kernel boot param 'selinux=0' - doing a few yum updates during this time too. Many of the files that were listed in the 'fixfiles relabel' run seemed as though they may have appeared during yum updates when 'selinux=0' or when selinux was disabled (by the /etc/sysconfig/selinux file settings). Boot params override this file. For the next few boots, I ran with 'selinux=1 enforcing=0' Just as a test, I ran 'fixfiles relabel' twice. The second time, there were no diagnostic output lines - leaving me with a good feeling. I booted up again and looked in the /var/log/messages file - no audit messages. Either something is working well, or not at all. --- Then I tried to boot with the boot param 'enforcing=1' In the RedHat nash phase (or maybe just after), I got the message: Enforcing mode requested, but no policy loaded. Halting now. Kernel panic: Attempted to kill init! ----- After a power cycle, I set the boot param back to 'enforcing=0' I remembered seeing a Makefile with the targets: ...,..., reload I believe this Makefile was in /etc/sysconfig/selinux/src/policy, but I noticed that /etc/sysconfig/selinux was now a file - in fact it was the file that I edited a few minutes before. Having seen a policy directory under /etc/syslinux/strict, I went there [root at hoho2 policy]# pwd /etc/selinux/strict/src/policy [root at hoho2 policy]# ls -lt | head total 11708 -rw-r--r-- 1 root root 97 May 29 23:57 reload.out drwxr-xr-x 2 root root 4096 May 29 23:57 tmp drwxr-xr-x 4 root root 4096 May 29 12:06 file_contexts -rw-r--r-- 1 root root 4207890 May 29 12:05 policy.conf drwx------ 2 root root 4096 May 29 12:05 flask drwx------ 3 root root 4096 May 29 12:05 macros drwx------ 2 root root 4096 May 29 12:05 types drwx------ 2 root root 4096 May 29 12:05 appconfig drwx------ 4 root root 4096 May 29 12:05 domains This is after I did a 'make reload 2>&1 | tee reload.out` twice. The first time I got a lot of diagnostic lines, 'inode ...'. The second time I got: [root at hoho2 policy]# cat reload.out /usr/sbin/load_policy /etc/selinux/strict/policy/policy.`cat /selinux/policyvers ` touch tmp/load This looked pretty good, so I tried to go into enforcing mode by doing [root at hoho2 policy]# setenforce 1 Immediately, I got: su[2804]: Error! Unable to set executable context (null). login (pam_unix)[2534]: session closed for user1 INIT: cannot execute "/sbin/mngetty" INIT: cannot execute "/sbin/mngetty" INIT: cannot execute "/sbin/mngetty" ... INIT: Id "1" respawing too fast, disabled for 5 minutes ----- Another power cycle, and I am ready for bed. Hopefully there are some clues in the above for selinux gurus. BobG on Sat, 29 May 2004 17:37:04 -0700, Tom London wrote: >I also had some issues in the newest selinux-policy installs from the >development tree. > >First, I had to remove setools to remove a yum/rpm conflict. > >After successfully yum'ing selinux-policy-strict-sources (which also >installed selinux-policy-strict and removed policy and policy-sources), >I rebooted in single user mode, where I did the usual 'fixfiles >relabel'. I then rebooted to multiuser mode, where I determined that >the 'mode' was set to 'disabled' (i.e., 'getenforce->disabled'). > >Rooting around uncovered that there was no /etc/selinux/config >installed, nor was /etc/sysconfig/selinux updated with the >'SELINUXTYPE=strict' line. Since the thread on this was confusing to >me, I also added a line 'POLICYTYPE=strict'). > >I modified /etc/syconfig/selinux copied it to /etc/selinux/config and >rebooted. Still came up with selinux in 'disabled' mode. > >Checking /var/log/messages showed 'SELinux disabled at boot'. So, I >rebooted adding 'selinux=1' to the boot line. This time, the boot failed >with 'can't read /etc/fstab' and brought me up in 'filesystem repair' >mode. There I determined that /etc/fstab had no security context >assigned to it (Did it get rewritten during a 'disabled' boot?) > >I rebooted without the 'selinux=1' but in single-user mode, where I >adjusted the context of /etc/fstab, /etc/sysconfig/selinux and >/etc/selinux/config. I also changed /etc/sysconfig/selinux to boot up >in permissive mode. > >Rebooting with 'selinux=1 single' worked, I reran 'fixfiles relabel'. > >Rebooting with 'selinux=1' into permissive/multi-user worked. I changed >/etc/sysconfig/selinux and /etc/selinux/config to 'enforce'. Rebooting >single-user (i.e., with 'selinux=1 single') worked. > >Rebooting strict/multi-user (i.e. with 'selinux=1') did not work. It >got jammed setting up X.org log files. Seems that >/var/log/Xorg.0.log.old had no security context so the attempt to move >/var/log/Xorg.0.log 'on top of it' failed. I'm guessing it was a >leftover from a 'disabled' boot.) > >I fixed that ('chcon --reference Xorg.0.log Xorg.0.log.old'), fixed >/tmp/gconfd-tbl (same problem), and now it boots up strict/multi-user. > >So here's the condensed version; >1. installing selinux-policy-strict-sources (and selinux-policy-strict) >did not setup /etc/selinux/config, nor did it modify >/etc/sysconfig/selinux. (I must admit that I was confused by the >message thread. Did I need to remove /etc/sysconfig/selinux before doing >the 'yum install selinux-policy-strict-sources'? I thought the install >would add the 'SELINUXTYPE=strict' line to an existing file, but I may >have read this wrong.) >2. My system was 'setup' to boot by default into 'disabled' mode. This >caused a lot of problems with unlabeled files, directories, etc. >Accidently forgetting to add 'selinux=1' to the boot line may cause this. >3. I had to 'yum remove setools'. Did this cause my booting or other >problems? >4. I added both 'SELINUXTYPE=' and 'POLICYTYPE=' lines to >/etc/sysconfig/selinux and to /etc/selinux/config. Are both >needed/correct? /sbin/fixfiles seems to want 'SELINUXTYPE'... >5. I manually copied /etc/selinux/conf from /etc/sysconfig/selinux. Does >that provide the correct info/format? > >System is up and running in strict/enforcing mode. I will later try to >install selinux-policy-targeted*. > >tom >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list From selinux at comcast.net Sun May 30 18:11:52 2004 From: selinux at comcast.net (Tom London) Date: Sun, 30 May 2004 11:11:52 -0700 Subject: Finding unlabeled files? Message-ID: <40BA23E8.8020807@comcast.net> I used the following to find files that are not labeled: find / -context 'null' -print 2>&1 | grep 'No data available' This prints out error messages of the form: getfilecon(/var/spool/cron/mailman): No data available getfilecon(/var/spool/at/.SEQ): No data available getfilecon(/initrd): No data available getfilecon(/initrd/sys): No data available getfilecon(/initrd/sbin): No data available getfilecon(/initrd/linuxrc): No data available etc. Is there a better/proper way of doing this? (If not, perhaps I'll write one...) The situation comes up when converting a system to SELinux, or if you accidently boot up an SELinux system in 'disabled' mode. I understand its 'safer' to run 'fixfiles relabel', but some vestigial unlabeled files seem to remain... Thanks, tom From bobgus at rcn.com Sun May 30 20:53:35 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Sun, 30 May 2004 15:53:35 -0500 Subject: Finding unlabeled files? (not selinux-enabled?) In-Reply-To: <40BA23E8.8020807@comcast.net> Message-ID: Hmm, what means this? [root at hoho2 root]# find / -context 'null' -print find: Error: invalid predicate -context: the kernel is not selinux-enabled. [root at hoho2 root]# od -c /selinux/enforce 0000000 0 0000001 [root at hoho2 root]# The boot param was set to 'selinux=1 enforcing=0' and I have lots of good looking SELinux lines in the /var/log/messages.1 file: [root at hoho2 log]# grep SELinux messages.1 ... May 30 00:09:17 hoho2 kernel: SELinux: Initializing. May 30 00:09:17 hoho2 kernel: SELinux: Starting in permissive mode May 30 00:09:18 hoho2 kernel: SELinux: Registering netfilter hooks [root at hoho2 log]# date Sun May 30 15:46:43 CDT 2004 [root at hoho2 log]# uptime 15:46:45 up 15:38, 3 users, load average: 0.00, 0.00, 0.00 [root at hoho2 log]# [root at hoho2 root]# cat /proc/version Linux version 2.6.6-1.397smp (bhcompile at tweety.build.redhat.com) (gcc version 3. 3.3 20040412 (Red Hat Linux 3.3.3-7)) #1 SMP Fri May 28 11:34:11 EDT 2004 [root at hoho2 root]# BobG On Sun, 30 May 2004 11:11:52 -0700, Tom London wrote: >I used the following to find files that are not labeled: > > find / -context 'null' -print 2>&1 | grep 'No data available' > >This prints out error messages of the form: > getfilecon(/var/spool/cron/mailman): No data available > getfilecon(/var/spool/at/.SEQ): No data available > getfilecon(/initrd): No data available > getfilecon(/initrd/sys): No data available > getfilecon(/initrd/sbin): No data available > getfilecon(/initrd/linuxrc): No data available >etc. > >Is there a better/proper way of doing this? (If not, perhaps I'll write >one...) > >The situation comes up when converting a system to SELinux, or if you >accidently boot up an SELinux system in 'disabled' mode. > >I understand its 'safer' to run 'fixfiles relabel', but some vestigial >unlabeled files seem to remain... > >Thanks, > tom From bleher at informatik.uni-muenchen.de Sun May 30 22:54:03 2004 From: bleher at informatik.uni-muenchen.de (Thomas Bleher) Date: Mon, 31 May 2004 00:54:03 +0200 Subject: Finding unlabeled files? In-Reply-To: <40BA23E8.8020807@comcast.net> References: <40BA23E8.8020807@comcast.net> Message-ID: <20040530225403.GB2027@jmh.mhn.de> * Tom London [2004-05-30 20:12]: > I understand its 'safer' to run 'fixfiles relabel', but some vestigial > unlabeled files seem to remain... Look into your policy for file contexts which specify "<>" as context. This means that setfiles does not touch these files at all, as they can not be properly labeled by looking at the file name; so it is best to leave them alone. If you come from a non-SELinux system you should probably delete all these files[0] and reboot. Thomas [0] the policy I'm looking right now has <> only for files which can be safely deleted if the system is in single user mode and is restarted immediately afterwards. -- http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA D09E C562 2BAE B2F4 ABE7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From selinux at comcast.net Mon May 31 05:33:15 2004 From: selinux at comcast.net (Tom London) Date: Sun, 30 May 2004 22:33:15 -0700 Subject: Finding unlabeled files? Message-ID: <40BAC39B.1030102@comcast.net> Thanks. However, I'm having a slightly different problem: because of various circumstances, some files that should be labeled appear to be unlabeled. I'm thinking that I missed the easy way: just running 'fixfiles check' or 'setfiles -n -v ...' tom ---------------------------------------------------------------- * From: Thomas Bleher * Tom London [2004-05-30 20:12]: > I understand its 'safer' to run 'fixfiles relabel', but some vestigial > unlabeled files seem to remain... Look into your policy for file contexts which specify "<>" as context. This means that setfiles does not touch these files at all, as they can not be properly labeled by looking at the file name; so it is best to leave them alone. If you come from a non-SELinux system you should probably delete all these files[0] and reboot. Thomas [0] the policy I'm looking right now has <> only for files which can be safely deleted if the system is in single user mode and is restarted immediately afterwards. From russell at coker.com.au Mon May 31 10:06:43 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 31 May 2004 20:06:43 +1000 Subject: Permission denied when building kernel In-Reply-To: <1085612449.1965.1.camel@localhost> References: <1085612449.1965.1.camel@localhost> Message-ID: <200405312006.43122.russell@coker.com.au> On Thu, 27 May 2004 18:39, Matthew East wrote: > I cannot build and install a kernel with selinux enabled. Here is what > happens towards the end of the modules_install stage: > > if [ -r System.map ]; then /sbin/depmod -ae -F System.map -b > /var/tmp/kernel-2.6.6-root -r 2.6.6; fi > WARNING: Couldn't open directory > /var/tmp/kernel-2.6.6-root/lib/modules/2.6.6: Permission denied > FATAL: Could not open > /var/tmp/kernel-2.6.6-root/lib/modules/2.6.6/modules.dep.temp for > writing: Permission denied > make[1]: *** [_modinst_post] Error 1 > error: Bad exit status from /var/tmp/rpm-tmp.11877 (%install) Steve suggested adding tmp_domain(depmod), that will allow search access to tmp_t, however I expect that /var/tmp/kernel-2.6.6-root/lib/modules/2.6.6 will have type sysadm_tmp_t so something like the following will probably do better: allow depmod_t tmp_t:dir search; rw_dir_create_file(depmod_t, sysadm_tmp_t) But the ideal solution (IMHO) would be to build kernels as non-root and non-sysadm_t. There is no reason why compiling a kernel should require administrative access, if it won't compile as a regular user then that's a bug and should be filed in bugzilla. user_t and staff_t can execute depmod_exec_t without a domain transition and won't have any problems in this regard. > audit(1085609097.359:0): avc: denied { search } for pid=17414 > exe=/sbin/depmod name=tmp dev=hda2 ino=196228 > scontext=root:sysadm_r:depmod_t tcontext=system_u:object_r:tmp_t > tclass=dir -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Mon May 31 10:33:42 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 31 May 2004 20:33:42 +1000 Subject: Script to check security? In-Reply-To: References: Message-ID: <200405312033.42090.russell@coker.com.au> On Sat, 29 May 2004 11:14, Bob Gustafson wrote: > The 'test suite', just like the build tool 'configure', would be a > collection of probes and test wrappers. SAS and Mathematica would also have > their own modular piece of the test script (and have their files properly > labeled). This MAY detect that the program operates correctly (which is more difficult than you may imagine in the case of programs that launch other programs in different domains - think of checking password access by pam_unix.so). However it does not help for the more difficult problems, such as determining that the program is not given excessive permissions. Many programs routinely try to access things that they don't need, one of the most difficult parts of writing SE Linux policy is deciding when to use a dontaudit rule for such things. > Perhaps these test script modules will converge to some common form which > can be customized a bit for the 'next' application. Much of the GNU build > process has evolved to mostly the same code for different applications - > just a few names are changed at a higher level. I've been trying to encourage post-grad students to do a Ph.D thesis on a related topic. So far no-one has been interested. It's generally regarded that this problem is not solvable in the general case, but I think that a good Ph.D project could get a usable partial solution. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From matthew.east at iue.it Mon May 31 16:40:50 2004 From: matthew.east at iue.it (Matthew East) Date: Mon, 31 May 2004 18:40:50 +0200 Subject: Permission denied when building kernel In-Reply-To: <200405312006.43122.russell@coker.com.au> References: <1085612449.1965.1.camel@localhost> <200405312006.43122.russell@coker.com.au> Message-ID: <1086021650.1766.2.camel@localhost> On Mon, 2004-05-31 at 12:06, Russell Coker wrote: > On Thu, 27 May 2004 18:39, Matthew East wrote: > > I cannot build and install a kernel with selinux enabled. Here is what > > happens towards the end of the modules_install stage: > > > > if [ -r System.map ]; then /sbin/depmod -ae -F System.map -b > > /var/tmp/kernel-2.6.6-root -r 2.6.6; fi > > WARNING: Couldn't open directory > > /var/tmp/kernel-2.6.6-root/lib/modules/2.6.6: Permission denied > > FATAL: Could not open > > /var/tmp/kernel-2.6.6-root/lib/modules/2.6.6/modules.dep.temp for > > writing: Permission denied > > make[1]: *** [_modinst_post] Error 1 > > error: Bad exit status from /var/tmp/rpm-tmp.11877 (%install) > > Steve suggested adding tmp_domain(depmod), that will allow search access to > tmp_t, however I expect that /var/tmp/kernel-2.6.6-root/lib/modules/2.6.6 > will have type sysadm_tmp_t so something like the following will probably do > better: > allow depmod_t tmp_t:dir search; > rw_dir_create_file(depmod_t, sysadm_tmp_t) OK thanks I will try that as well! You are right that the previous suggestion didn't do the trick. > But the ideal solution (IMHO) would be to build kernels as non-root and > non-sysadm_t. There is no reason why compiling a kernel should require > administrative access, if it won't compile as a regular user then that's a > bug and should be filed in bugzilla. user_t and staff_t can execute > depmod_exec_t without a domain transition and won't have any problems in this > regard. Yes in the README file with the kernel source it underlines that one should compile as user, and then su to install. But I was using the command "make rpm" as I thought that if I didn't install the kernel as an rpm, then it might cause difficulties for the other rpm packages which depended on the kernel. The "make rpm" command seems to require you to be root, possibly (I'm no expert) as it uses the /usr/src/redhat area. Thanks everyone for their help!! Matt From wolfy at zig-zag.net Mon May 31 17:38:59 2004 From: wolfy at zig-zag.net (lonely wolf) Date: Mon, 31 May 2004 20:38:59 +0300 Subject: Permission denied when building kernel In-Reply-To: <1086021650.1766.2.camel@localhost> References: <1085612449.1965.1.camel@localhost> <200405312006.43122.russell@coker.com.au> <1086021650.1766.2.camel@localhost> Message-ID: <40BB6DB3.5060405@zig-zag.net> Matthew East wrote: >Yes in the README file with the kernel source it underlines that one >should compile as user, and then su to install. But I was using the >command "make rpm" as I thought that if I didn't install the kernel as >an rpm, then it might cause difficulties for the other rpm packages >which depended on the kernel. The "make rpm" command seems to require >you to be root, possibly (I'm no expert) as it uses the /usr/src/redhat >area. > use http://erizo.ucdavis.edu/~dmk/notes/RPMs/Creating_RPMs.html as a guide for how to build rpm packages as normal user. ps1: %_topdir is enough to build rpm. the %_tmppath is just a security addon. ps2: i have never succeeded in building rpm of non-modular kernels. "make rpm" fails while triyng the " make modules " part. From emf at obfuscation.org Mon May 31 19:08:33 2004 From: emf at obfuscation.org (Erik Fichtner) Date: Mon, 31 May 2004 12:08:33 -0700 Subject: Simplistic X11 logins not working.. (newbie questions) Message-ID: <20040531190833.GB7869@obfuscation.org> So. I've got vanilla FC2 with SELinux loaded and the standard policy sources loaded on my laptop. For various reasons (low memory and a general dislike for all things GNOME; primarily), I'm trying to make good old xdm work and start boring old twm. This requires a little bit of manhandling within /etc/X11/xdm/Xsession and /etc/inittab. No big deal here. As packaged, the policy sets up xdm running as system_u:system_r:xdm_t. This starts a copy of X which is transitioned into system_u:system_r:xdm_xserver_t. Then there's a display ":0" sitting around on a third pid running as system_u:system_r:xdm_t. Fine. Logging in as my user (which results in a nice clean emf:user_r:user_t on the console) launches a twm as system_u:system_r:xdm_t, and then when I attempt to run an Xterm; i get the following avc denies: avc: denied { read write } for pid=3793 exe=/usr/bin/xterm name=ptmx dev=hda2 ino=134859 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:ptmx_t tclass=chr_file avc: denied { search } for pid=3793 exe=/usr/bin/xterm dev= ino=1 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:devpts_t tclass=dir avc: denied { search } for pid=3793 exe=/usr/bin/xterm dev= ino=1 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:devpts_t tclass=dir and xterm promptly exits since it can't get a pty, and everything is still running as system_r:xdm_t; the real issue here. /etc/security/default_contexts does have an entry for: system_r:xdm_t staff_r:staff_t user_r:user_t sysadm_r:sysadm_t I even tried changing that to read: system_r:xdm_t user_r:user_t At this point, I started flailing around a little bit and created an Xwm.{te|fc} pair: type Xwm_exec_t, file_type, sysadmfile, exec_type; domain_auto_trans(xdm_t,Xwm_exec_t,user_t) /usr/X11R6/bin/twm system_u:object_r:Xwm_exec_t reloaded the policy, and relabelled twm. Alles gut, ya? Nein! Now, when xdm->Xsession fires off twm, i get this: security_compute_sid: invalid context system_u:system_r:user_t for scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:Xwm_exec_t tclass=process and twm exits. Clearly, that wasn't the answer. So..... Questions are: 1) why doesn't default_contexts appear to have any influence upon xdm? 1a) is there a way to force it? 2) what am I supposed to do to get my window manager and its children into user_r:user_t ? Thanks in advance... -- Erik Fichtner; Unix Ronin