September 2004 - selinux - Fedora mailing-lists

Domains, interpreted languages, and Cron scripts
by Bill McCarty 23 Nov '04

23 Nov '04

Hi all, I've run into an architectural headache that someone else must already have visited, and perhaps solved. But, I find no mention of the problem in list archives or elsewhere. I have several Python scripts that run under Cron. Some of these scripts access or modify sensitive data, and so I'd like to define one or more domains by means of which to limit their privileges. However, the exe name associated with such scripts is /usr/bin/python2.3, rather than the name of the script. Consistent with the principle of least privilege, I'd prefer to define distinct domains for each script, rather than an overly broad python_t domain, for instance. Has anyone else been here already? What techniques are useful for constraining the privileges given to scripts? One idea: Would it be a good thing to modify Run-parts to transition to a domain named for the Cron script it launches? Doing so would seem to solve my problem, but it might create others <g>. Thanks, -- Bill McCarty, Ph.D. Professor of Information Technology Azusa Pacific University

5 9

Re: Turn on SELinux
by chris albert 11 Nov '04

11 Nov '04

On Sat, 2004-06-05 at 09:11, Khurt Williams wrote: >> I installed Fedora Core 2. I did not enable selinux at install. How >> do I now enable it? > >>This may help >>http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/ But it doesn't. I filed a bugzilla request for having post-install-without-selinux selinux installation instructions added to the faq. I used S.Smalley's remark at the end of https://listman.redhat.com/archives/fedora-selinux-list/2004-May/msg00202.h… Chris

5 5

ReiserFS
by Russell Coker 06 Oct '04

06 Oct '04

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134111 We are having some discussions of ReiserFS in the Red Hat bugzilla. fs_use_xattr reiserfs system_u:object_r:fs_t; It seems to me that the easiest solution is to remove the above line from fs_use and add the following to genfs_contexts: genfscon reiserfs / system_u:object_r:nfs_t The reason for this hack is that we already have the policy for home directories on NFS. ReiserFS will never work for a root FS and isn't worth any more effort than this hack. Another suggestion was to entirely remove ReiserFS support from Fedora (IE no reiserfs.ko file in the kernel package). -- 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

2 2

checkinstall on Fc3T2
by aq 04 Oct '04

04 Oct '04

hello, I am compiling openbox-3.2 from source code (yes, FC3T2 is test edition, so nobody makes packages for it). I run "./configure", then "make". But when I run checkinstall to make a rpm package of openbox, I got various errors (for ex, "Segmentation fault mkdir data 2 & > /dev/null). I guess the problem is that the "checkinstall" has insufficient privilege. What should I do to fix this problem? thank you a lot, AQ

2 1

FC2 Selinux boot failure
by deff 29 Sep '04

29 Sep '04

My fedora core 2 selinux ceased to function. dmesg: Security Scaffold v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode There is already a security framework initialized, register_security failed. selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary sestatus -v: SELinux status: disabled What's wrong? Can't manage to boot it at least to permissive. Only thing I've messed recently was nss authentification via ldap. deff

3 4

Conflicting types message
by Stephen John Smoogen 29 Sep '04

29 Sep '04

/etc/cron.daily/fixfiles.cron: logging to /dev/null /usr/sbin/setfiles: conflicting specifications for /lib/tls/i486/libdb-4.2.so and /lib/tls/i586/libdb-4.2.so, using system_u:object_r:shlib_t. Null message body; hope that's ok I got this morning from the badcontexts file. Do not know enough about SElinux to figure out what is causing this... -- Stephen J Smoogen. Professional System Administrator

1 0

/var/tmp/badcontext
by Stephen John Smoogen 28 Sep '04

28 Sep '04

What should users do with the files listed in /var/tmp/badcontext? For the last 3 days I have had over 10000 files listed since I installed it. I was wondering if I should be running some command after a yum upgrade that I didnt know about ;). 17287 /var/tmp/badcontext.HNjBUG2517 52272 /var/tmp/badcontext.XzqEZB4859 22518 /var/tmp/badcontext.YGZFP27816 -- Stephen J Smoogen. Professional System Administrator

3 3

setools-1.4.1 patch
by Don Patterson 27 Sep '04

27 Sep '04

A new bug report (with a patch attached) has been entered into Fedora bugzilla (http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133811) which addresses a few bugs in the setools-1.4.1 package that have been brought to our attention. Also, an updated setools-1.4.1 tarball is available from our website at http://www.tresys.com/selinux/selinux_policy_tools.html. Thanks. Don Patterson Tresys Technology http://www.tresys.com

1 0

/lib/tls/i[456]86/libdb-4.2.so - patch to types.fc
by Tom London 27 Sep '04

27 Sep '04

Running 'setfiles -vv $FC /lib' produces: setfiles: labeling files under /lib setfiles: relabeling /lib/tls/i586/libdb-4.2.so from system_u:object_r:shlib_t to system_u:object_r:lib_t setfiles: conflicting specifications for /lib/tls/i486/libdb-4.2.so and /lib/tls/i586/libdb-4.2.so, using system_u:object_r:shlib_t. setfiles: relabeling /lib/tls/i486/libdb-4.2.so from system_u:object_r:lib_t to system_u:object_r:shlib_t Suggest this patch: --- types.fc 2004-09-23 11:02:38.000000000 -0700 +++ /tmp/types.fc 2004-09-24 22:35:40.913346939 -0700 @@ -302,7 +302,7 @@ /lib(64)?/[^/]*/lib[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t /lib(64)?/security/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t /lib(64)?/tls/i686/cmov/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t -/lib(64)?/tls/i486/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t +/lib(64)?/tls/i[456]86/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t # # /sbin tom -- Tom London

3 2

reconnecting USB p rinter
by Tom London 26 Sep '04

26 Sep '04

Running strict/enforcing, w/USB printer. Reconnecting printer (after pulling the plug) yields the following: Sep 25 18:46:47 fedora kernel: audit(1096163207.182:0): avc: denied { search } for pid=7592 exe=/usr/sbin/hal_lpadmin name=cups dev=hda2 ino=4474131 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:cupsd_etc_t tclass=dir Sep 25 18:46:48 fedora kernel: audit(1096163208.050:0): avc: denied { read } for pid=7593 exe=/usr/bin/python name=printconf_tui.py dev=hda2 ino=4309021 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:printconf_t tclass=file Sep 25 18:46:48 fedora kernel: audit(1096163208.050:0): avc: denied { getattr } for pid=7593 exe=/usr/bin/python path=/usr/share/printconf/util/printconf_tui.py dev=hda2 ino=4309021 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:printconf_t tclass=file Sep 25 18:46:49 fedora kernel: audit(1096163209.538:0): avc: denied { read } for pid=7595 exe=/usr/bin/perl name=urandom dev=tmpfs ino=965 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file Attached patch to cups.te adds allow rules for these. Please correct/edit/etc. tom -- Tom London

2 3

fsck.ext3 on bootup
by Tom London 26 Sep '04

26 Sep '04

Get these very early during boot up. I'm guessing we're trying to check the 'early root' and that this is harmless. If so, dontaudit fsadm_t device_t:blk_file { getattr }; That sound right? tom Sep 16 10:50:36 fedora kernel: ACPI: Sleep Button (CM) [FUTS] Sep 16 10:50:36 fedora kernel: audit(1095357002.303:0): avc: denied { getattr } for pid=1839 exe=/sbin/fsck.ext3 path=/dev/root dev=tmpfs ino=2028 scontext=system_u:system_r:fsadm_t tcontext=system_u:object_r:device_t tclass=blk_file Sep 16 10:50:36 fedora kernel: EXT3 FS on hda2, internal journal Sep 16 10:50:36 fedora kernel: device-mapper: 4.1.0-ioctl (2003-12-10) initialised: dm(a)uk.sistina.com Sep 16 10:50:36 fedora kernel: audit(1095357004.327:0): avc: denied { getattr } for pid=2074 exe=/sbin/fsck.ext3 path=/dev/root dev=tmpfs ino=2028 scontext=system_u:system_r:fsadm_t tcontext=system_u:object_r:device_t tclass=blk_file

3 7

hald - r/w access to /dev/usb/lp0?
by Tom London 25 Sep '04

25 Sep '04

When haldaemon starts, and typically just after the text 'login:' appears but before the graphical stuff takes over, I get: Sep 25 10:28:57 fedora kernel: audit(1096133337.944:0): avc: denied { read write } for pid=3187 exe=/usr/sbin/hald name=lp0 dev=tmpfs ino=5073 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:printer_device_t tclass=chr_file referring to /dev/usb/lp0. Does hald need read/write access to the printer_device? Seems strange, but if so, we need to add to hald.te. If not, any idea what's happening? tom -- Tom London

2 3

setenforce notice to dbus, 13 minute delay?
by Tom London 25 Sep '04

25 Sep '04

I notice that when I do 'setenforce', dbus is notified. But there appears to be a significant delay, e.g., 13-15 minutes, before dbus logs it. Is this just log buffer 'flush buffer' timing? Is this to be expected? thanks, tom Sep 25 10:29:54 fedora kernel: audit(1096133394.349:0): avc: granted { setenforce } for pid=4107 exe=/usr/bin/setenforce scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:security_t tclass=security <SNIP> Sep 25 10:43:21 fedora dbus: avc: received setenforce notice (enforcing=0) -- Tom London

2 1

cups.te: ptal_t needs to read usbfs_t
by Tom London 25 Sep '04

25 Sep '04

When hpoj starts, it produces the following: Sep 25 10:28:24 fedora kernel: audit(1096133304.072:0): avc: denied { read } for pid=2769 exe=/usr/sbin/ptal-mlcd dev=usbfs ino=2309 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:usbfs_t tclass=dir ptal_t already has 'r_dir_file(ptal_t, usbdevfs_t)'. Suggest adding 'r_dir_file(ptal_t, usbfs_t)' [Are both still needed?] tom --- cups.te 2004-09-23 11:02:38.000000000 -0700 +++ /tmp/cups.te 2004-09-25 10:57:11.147771270 -0700 @@ -156,6 +156,7 @@ allow ptal_t printer_device_t:chr_file { ioctl read write }; allow ptal_t { etc_t etc_runtime_t }:file { getattr read }; r_dir_file(ptal_t, usbdevfs_t) +r_dir_file(ptal_t, usbfs_t) allow cupsd_t ptal_var_run_t:sock_file { write setattr }; allow cupsd_t ptal_t:unix_stream_socket { connectto }; allow cupsd_t ptal_var_run_t:dir { search }; -- Tom London

1 0

firefox, gaim, /lib/ld-2.3.3.so ?
by Tom London 25 Sep '04

25 Sep '04

After being on the road for a bit, I did a 'yum update' to grab the new stuff. After doing so (>300 packages), running strict/enforcing, firefox and gaim fail to start: Sep 23 20:10:29 fedora kernel: audit(1095995429.976:0): avc: denied { write } for pid=4755 path=/lib/ld-2.3.3.so dev=hda2 ino=3178536 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:ld_so_t tclass=file Sep 23 20:10:31 fedora kernel: audit(1095995431.164:0): avc: denied { unlink } for pid=4755 exe=/usr/lib/firefox-0.10.0/firefox-bin name=.fonts.cache-1 dev=hda2 ino=2752979 scontext=user_u:user_r:user_mozilla_t tcontext=user_u:object_r:user_home_t tclass=file and Sep 23 20:26:51 fedora kernel: audit(1095996411.010:0): avc: denied { write } for pid=4838 path=/lib/ld-2.3.3.so dev=hda2 ino=3178536 scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t tclass=file Running in permissive mode both start, and /lib/ld-2.3.3.so is not written to. Write to /lib/ld-2.3.3.so ????? Did I do something stupid? tom -- Tom London

2 4

RE: What is SELinux targeted policy?
by Alex Ackerman 24 Sep '04

24 Sep '04

>-----Original Message----- >From: fedora-selinux-list-bounces(a)redhat.com on behalf of Daniel J Walsh >Sent: Mon 9/20/2004 5:35 PM >To: For users of Fedora Core releases; Fedora SELinux support list for users & developers.; Development discussions related to Fedora Core >Subject: What is SELinux targeted policy? >Strict policy is still available but will be not be installable >directly, you can use selinux-config-securitylevel to turn it on >and relabel the file system. Does this mean the strict policy will not work on a Fedora Core system at all or that it will take some customization prior to working effectively? Also, are there plans to support te domains for either Sendmail or Postfix via the SELinux policy in the near future? What about PostgreSQL/MySQL? Thanks! Alex Ackerman http://www.darkhonor.com

3 2

updated SELinux FAQ
by Karsten Wade 24 Sep '04

24 Sep '04

Fedora Core 3 test 2: http://fedora.redhat.com/docs/selinux-faq-fc3test2/ (v. 1.3-1) Fedora Core 2: http://fedora.redhat.com/docs/selinux-faq-fc2/ (v. 1.2-8) 1. Notice the new URLs. These are permanent homes. Currently, the copies on people.redhat.com are up-to-date, and I will work out some form of redirect in the near future. 2. Content *should* be technically updated to match test2. If not, see 3. 3. If you have bugs or additional questions (and hopefully answers), use the bugzilla form that is linked from the first Tip box "Making changes/additions to the Fedora SELinux FAQ". 4. A few new questions in this version: Q: What is the SELinux targeted policy? Q: What daemons are protected by the targeted policy? Q: Which daemons will you add to the targeted policy? How about Sendmail, Postfix, MySQL, or PostgreSQL? Q: What about the strict policy? Does it even work? Q: How do I install/not install SELinux? Q: How do I switch the policy I'm using? Q: How do I enable/disable SELinux protection on specific daemons under the targeted policy? Q: Why does SELINUX=disabled not work for me? 5. Lifecycle comments: I'll maintain this FAQ as long as it is useful. This FAQ is particular to each version of Fedora Core. Each version of this FAQ will follow the version of Fedora to the Legacy Project, when the time comes. - Karsten -- Karsten Wade, RHCE, Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41

1 0

get the red and green back (really consoletype, rhgb)
by Tom London 24 Sep '04

24 Sep '04

Booting in strict/enforcing, 'Fedora' in the 'Welcome to Fedora Core' message is no longer red, the subsequent 6 or so messages are formatted differently (i.e., the '[OK]' is not nicely indented, and it is not in green). Also, rhgb doesn't start. (Yeah, I know, this is not a bug, its a feature ;) ) Anyway, the following patch puts the red and green back in the boot. The change mimics the privileges given for console_device_t:chr_file --- /etc/selinux/strict/src-1.17.16-3/policy/domains/program/consoletype.te 2004-09-16 07:14:24.000000000 -0700 +++ ./consoletype.te 2004-09-16 11:37:14.000000000 -0700 @@ -52,5 +52,5 @@ allow consoletype_t pam_var_run_t:file { getattr read }; ') ifdef(`distro_redhat', ` -dontaudit consoletype_t tmpfs_t:chr_file { read write }; +allow consoletype_t tmpfs_t:chr_file { getattr ioctl read write }; ') The follow makes rhgb work in strict/enforcing. The problem is that it wants to mount /etc/rhgb, but it is currently labeled 'etc_t'. Labeling /etc/rhgb as 'root_t' makes it work. Not sure if this is really 'proper'. I'd be more comfortable with it being labeled something like 'etc_rhgb_t' or some such, or moving the mount point.... --- /etc/selinux/strict/src-1.17.16-3/policy/file_contexts/program/rhgb.fc 2004-09-16 07:14:24.000000000 -0700 +++ ./rhgb.fc 2004-09-16 12:21:12.424588200 -0700 @@ -1,2 +1,3 @@ /usr/bin/rhgb -- system_u:object_r:rhgb_exec_t #/etc/dbus-1(/.*)? system_u:object_r:etc_dbusd_t +/etc/rhgb -d system_u:object_r:root_t

4 6

mount ?
by Tom London 23 Sep '04

23 Sep '04

Running strict/enforcing, with latest from Dan's tree. The 'mount' command produces no output when run in enforcing mode. Works fine in permissive mode. No AVCs produced..... tom

5 5

mailman...
by Tom London 23 Sep '04

23 Sep '04

Running strict/enforcing, latest packages from Dan's tree. Argh... mailman again. Here's the avc: Sep 15 20:40:02 fedora kernel: audit(1095306002.105:0): avc: denied { getattr } for pid=20117 exe=/usr/bin/python path=/var/mailman/pythonlib/korean/__init__.pyc dev=hda2 ino=444330 scontext=system_u:system_r:mailman_queue_t tcontext=system_u:object_r:var_t tclass=file occurs every 5 minutes (so generates lots of error'ed emails). Mailman requires python 'stuff' from /var/mailman/pythonlib and from /var/mailman/Mailman. I can think of 2 possible fixes: 1. Explicitly allow mailman_queue_t to read var_t: --- mailman.te 2004-09-15 12:53:30.000000000 -0700 +++ /etc/selinux/strict/src-1.17.14-1.patched/policy/domains/program/mailman.te2004-09-14 16:36:43.000000000 -0700 @@ -31,7 +31,7 @@ can_network(mailman_$1_t) can_ypbind(mailman_$1_t) allow mailman_$1_t self:unix_stream_socket create_socket_perms; -allow mailman_$1_t var_t:dir r_dir_perms; +r_dir_file(mailman_$1_t, var_t) ') mailman_domain(queue, `, auth_chkpwd') or 2. by relabeling the .py, .pyc and .pyo files in /var/mailman/pythonlib and /var/mailman/Mailman as shlib_t (or something else?) i.e. adding this to mailman.fc: /var/mailman/pythonlib(/.*)?/.*\.py([co])? -- system_u:object_r:shlib_t /var/mailman/Mailman(/.*)?/.*\.py([co])? -- system_u:object_r:shlib_t I'm not sure that shlib_t is correct. (Should it be mailman_queue_t?) But I noticed an entry in types.fc for .so files in the pythonlib tree, and copied that. tom

4 3

AVCs with ntpd
by Felipe Alfaro Solana 22 Sep '04

22 Sep '04

OK, so I'm trying SElinux after having it disabled for some time. That's what I did: 1. Installed selinux-policy-targeted-1.17.16-2 2. Recompiled the kernel with SElinux support 3. Booted into single user mode 4. Ran "fixfiles relabel" 5. Rebooted with "selinux=1" Now, I'm seeing a lot of these: audit(1095681913.039:0(: avc: denied { search } for pid=2515 exe=/usr/sbin/ntpd dev=tmpfs ino=357 scontext=user_u:system_r:ntpd_t tcontext=user_u:object_r"tmpfs_t tclass=dir The problem here is that I'm using UDEV and that the initial ramdisk mounts a tmpfs on top of "/dev", thus, covering the labeled "/dev" that resides on disk. How should I fix this?

5 5

More AVCs during boot
by Felipe Alfaro Solana 21 Sep '04

21 Sep '04

Hi! With selinux-policy-targeted, I get this during boot: audit(1095721178.335:0): avc: denied { associate } for pid=508 exe=/sbin/restorecon name=initctl dev=tmpfs ino=1992 scontext=system_u:object_r:initctl_t tcontext=system_u:object_r:tmpfs_t tclass=filesystem audit(1095721179.084:0): avc: denied { associate } for pid=721 exe=/usr/sbin/setfiles name=initctl dev=tmpfs ino=1992 scontext=system_u:object_r:initctl_t tcontext=system_u:object_r:tmpfs_t tclass=filesystem which seem related related to "/dev/initctl". audit(1095721179.097:0): avc: denied { associate } for pid=721 exe=/usr/sbin/setfiles name=.udev.tdb dev=tmpfs ino=366 scontext=system_u:object_r:udev_tbl_t tcontext=system_u:object_r:tmpfs_t tclass=filesystem which is related to /dev/.udev.tdb audit(1095714008.289:0): avc: denied { setrlimit } for pid=2218 exe=/usr/sbin/named scontext=user_u:system_r:named_t tcontext=user_u:system_r:named_t tclass=process related to bind audit(1095714008.771:0): avc: denied { read } for pid=2251 exe=/usr/sbin/ntpd name=drift dev=hda2 ino=10289214 scontext=user_u:system_r:ntpd_t tcontext=system_u:object_r:file_t tclass=file related to ntpd. Any ideas?

2 3

SELinux Symposium Call for Presentation Proposals
by Frank Mayer 21 Sep '04

21 Sep '04

CALL FOR PRESENTATION PROPOSALS FIRST SECURITY ENHANCED LINUX SYMPOSIUM (www.selinux-symposium.org) The inaugural symposium on Security Enhanced Linux (SELinux) will be held March 2-4 2005 in the Silver Spring, Maryland, USA (near Washington, DC). SELinux brings the power of flexible mandatory access control such as type enforcement to Linux. The symposium is an opportunity to learn about SELinux and share technical and application experiences. The call for presentation and tutorial proposals is now open until October 1, 2004. All proposals will be reviewed by the review committees for inclusion in the symposium agenda. To submit proposals visit http://www.selinux-symposium.org.

1 1

What is SELinux targeted policy?
by Daniel J Walsh 20 Sep '04

20 Sep '04

When FC2 was released we attempted to add the NSA strict policy to the operating system. We were able to find hundreds of problems in the policy and we quickly found out that users who customized their environments in unexpected ways caused SELinux and the OS to conflict. We decided at that point to take a step back and go with a strategy where we would lock down a few daemons with SELinux and allow the rest of the system to run in the same manner with or without SELinux. Targeted policy was born. In targeted policy most processes run in a unconfined_t domain, which means for the most part they are not being confined by the SELinux policy. They are still governed by Standard unix security, but not effected by SELinux. Certain network daemons have policy and the unconfined_t policy transitions to those policies when the application starts. So when the system boots init runs in the unconfined_t policy, but when named starts up it transitions to the named_t domain and is locked down. We use the following policies nscd.te apache.te dhcpd.te named.te ntpd.te portmap.te snmpd.te squid.te syslogd.te Also users can select which daemons he want to have SELinux to protect via system-config-securitylevel. So if an admin finds that SELinux will not allow his apache web server to run the way he wants he can turn off the transition. This will drop it back to normal Unix protections, but all other daemons will continue to be protected by SELinux. Through the use of these "boolean" values the admin can increase or decrease the level of protection SELinux provides. In the future we plan on adding additional Domains that SELinux will protect. Strict policy is still available but will be not be installable directly, you can use selinux-config-securitylevel to turn it on and relabel the file system. Dan

1 0

Variable naming confusion
by Bob Gustafson 20 Sep '04

20 Sep '04

To me, there is a lot of confusion in the naming and choice of values of the SELINUX booleans. (Maybe I just don't have my head around the concepts.. - but I don't think I am alone) For example: The variable 'SELINUX' in the file /etc/selinux/config has the value choices 'enforcing' or 'permissive'. The variable 'enforce' in the /boot/grub/grub.conf file has the value choices '=0' or '=1' The variable shown by the command 'getenforce' is either 'Permissive' or 'Enforcing' (note the initial capitalization) When using the runtime command 'setenforce', the argument is either '0' or '1' When using the script command 'selinuxenabled', the result is '0' if it IS enabled. Suggestions The variable 'SELINUX' is either 'enabled' or 'disabled' The variable 'enforcing' is either 'enabled' or 'disabled' (This can be named 'enforce' rather than 'enforcing' - would help when trying to remember whether the runtime command is 'setenforce' or 'setenforcing') The variable 'SELINUXTYPE' is 'strict', 'targeted', 'myownpolicy', 'strangleddaemons', etc.

3 3

Bug 129584: restrictions on user_t
by Ivan Gyurdiev 19 Sep '04

19 Sep '04

Bug link: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129584 > Additional Comment #9 From Daniel Walsh (dwalsh(a)redhat.com) on > 2004-09-15 15:55 > Yes there are a lot of files that user can not access. Mainly any > file that has a security context associated with it and doesn't have > the attribute usercanread. > Again I want to bring this conversation to the public list and come to > concensus. We can add usercanread to these files, but the question > than is should a user be able to read all files even if they are world > readable. I don't see why not. If you think the user should not be able to read those files, then why aren't their permissions flags set accordingly? If a file was intended to be readable only by a certain application or only by root then it could have had the proper user/group/rwx flags set - this restriction could have been imposed without SELinux. If it is marked user readable then it seems to me that any user should be able to read it (or at least that there are no security reasons to deny it). So why does SElinux impose restrictions on user_t that contradict this explicit setting? -- Ivan Gyurdiev <ivg2(a)cornell.edu> Cornell University

3 2

lsusb
by Tom London 19 Sep '04

19 Sep '04

Running strict/enforcing, latest Rawhide packages including latest from Dan's tree (selinux-policy-strict-1.17.18-2). Running 'lsusb' as root fails, but '/sbin/lsusb' as user works. [root@fedora ~]# lsusb cannot open /proc/bus/usb, Permission denied (13) Works in permissive mode. Here are the avc's from permissive mode: Sep 18 20:45:36 fedora kernel: audit(1095565536.018:0): avc: denied { read } for pid=13020 exe=/sbin/lsusb dev=usbfs ino=2335 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:usbfs_t tclass=dir Sep 18 20:45:36 fedora kernel: audit(1095565536.018:0): avc: denied { getattr } for pid=13020 exe=/sbin/lsusb path=/proc/bus/usb dev=usbfs ino=2335 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:usbfs_t tclass=dir Sep 18 20:45:36 fedora kernel: audit(1095565536.019:0): avc: denied { search } for pid=13020 exe=/sbin/lsusb dev=usbfs ino=2335 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:usbfs_t tclass=dir Sep 18 20:45:36 fedora kernel: audit(1095565536.019:0): avc: denied { read } for pid=13020 exe=/sbin/lsusb name=001 dev=usbfs ino=6351 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:usbfs_t tclass=file These look like: r_dir_file(sysadm_t, usbfs_t) r_dir_file($1_t, usbfs_t) is in user_macros.te. Should it be in base_user_macros.te? Included in admin_macros.te? tom -- Tom London

2 1

Re: please try SELinux again
by Colin Walters 18 Sep '04

18 Sep '04

On Sat, 2004-09-18 at 23:19 +0200, Lars wrote: > > when i try to enable selinux it only boots to the message > "setting up local disks" in rhgb and stays there. Hmm. Are you running the latest rawhide? Does it work again when you add enforcing=0 to the boot line? [We should move this discussion to fedora-selinux-list]

1 0

please try SELinux again
by Colin Walters 18 Sep '04

18 Sep '04

Hi, Talking with a number of people at the office, it seems a high percentage of Fedora developers disabled SELinux during FC2 test2, which was our first attempt at SELinux. Many other users and testers in the Fedora community likely did so as well. I think a lot of people are not aware that things have changed (and generally improved) dramatically since then. Instead of the original "strict" policy which covered everything, a new "targeted" policy has been developed which only applies SELinux restrictions to a few select system daemons. Regular user login sessions are unrestricted. This targeted policy will be enabled by default for FC3. But those of you who are upgrading from existing systems, if you earlier added selinux=0 to your grub config, or disabled it in /etc/sysconfig/selinux, will not be testing the new policy. Please: undo those changes, and give it another try. Be sure that /etc/sysconfig/selinux has these two lines: SELINUX=enforcing SELINUXTYPE=targeted Also be sure you don't have selinux=0 in your grub configuration.

1 0

Boolean utilities segv's
by George C. Wilson 17 Sep '04

17 Sep '04

Hi, We found what appears to be a bug in libselinux. The getsebool, setsebool, and togglesebool all SIGSEGV when SELINUX=disabled. The global that stores the selinuxfs mountpoint in libselinux, selinux_mnt, is initialized to NULL. selinuxfs is not mounted when SELinux is disabled, therefore no mountpoint exists when init_selinuxmnt() scans /proc/mounts, and selinux_mnt remains NULL. So when get_bool_value() in booleans.c attempts to strlen(selinux_mnt), a SIGSEGV results. The fix is to validate selinux_mnt before the offending strlen() in get_bool_value(), line 101 of booleans.c from selinux-usr-2004081908. It probably would not hurt to validate name as well. The same bug exists in FC3. Thanks -- George Wilson <ltcgcw(a)us.ibm.com> IBM Linux Technology Center

3 3

/dev/dri/* and SE Linux
by Russell Coker 17 Sep '04

17 Sep '04

In the latest CVS SE Linux policy xserver_macros.te has: # Create and access /dev/dri devices. allow $1_xserver_t device_t:dir { setattr rw_dir_perms }; allow $1_xserver_t dri_device_t:chr_file create_file_perms; [...] # Do not flood audit logs due to device node creation attempts. dontaudit $1_xserver_t device_t:chr_file create; [...] allow $1_xserver_t device_t:dir { create }; It seems that the first and second sections don't work well together. Since we changed /dev/dri to have type device_t instead of dri_device_t it seems that attempts to create /dev/dri/whatever will be permitted on the device_t:dir access but dontaudit'd on the device_t:chr_file access. Does it even make sense to allow creating device nodes under /dev/dri now that we have udev doing so much? Can't udev do this for us? -- 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

3 5

SELinux & apache/httpd access to /home/*/www
by Cream 17 Sep '04

17 Sep '04

Hello, My problem is this: I host some small PHP & MySQL websites for friends and family, they have their VirtualHost DocumentRoot's in "/home/[name]/www" (and is working fine with SELinux disabled). I am running SELinux with SELINUX=enforcing, SELINUXTYPE=targeted. SELinux seems to be blocking httpd from accessing /home/name/www, atleast when trying to start apache it complains: Starting httpd: Warning: DocumentRoot [/home/xxxxxx/www] does not exist Warning: DocumentRoot [/home/yyyyy/www] does not exist [FAILED] (The non virtualhost root in /var/www/html works fine, but if moved to /home/xxxxxx/www it fails) /etc/selinux/targeted/contexts/files/file_contexts contains: # apache /home/[^/]+/((www)|(web)|(public_html))(/.+)? system_u:object_r:httpd_user_content_t Which to me would seem to match the /home/[name]/www (I have tried upgrading to selinux-policy-targeted-1.17.12-1, but it didnt fix the problem) (I have the individual logfiles in /home/[name]/log, which probably presents another problem.) I dont quite understand the quirks of SELinux, so I'd certainly appriciate some direction. Regards Kris PS. If what I'm asking is simple, please bare with me, i installed Fedora Core 3 test1 only 2 days ago, and its my first experience with SELinux (I spent most of yesterday google'ing for answers to my problem, and reading up on SELinux permissions. Without learning much.) PPS. Does anyone have context files for Qmail / QmailAdmin / SQWebmail / Vpopmail / courier-imap Qmail-Scanner / SpamAssassin / ClamAV / maildrop / daemontools / ucspi-tcp-0.88 (tcpserver) / ezmlm ? :) (I wouldn't building them if i could only figure out how)

3 13

cups, /dev/fd
by Tom London 17 Sep '04

17 Sep '04

Running strict/enforcing, latest from Dan's tree. Printing (say, from openoffice) yields: Sep 16 18:01:39 fedora kernel: audit(1095382899.718:0): avc: denied { read } for pid=10941 exe=/usr/bin/perl name=fd dev=tmpfs ino=2794 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:device_t tclass=lnk_file Sep 16 18:01:39 fedora kernel: audit(1095382899.718:0): avc: denied { read } for pid=10941 exe=/usr/bin/perl name=fd dev=tmpfs ino=2794 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:device_t tclass=lnk_file inode 2794 is /dev/fd. Make sense to add? dontaudit cupsd_t device_t:lnk_file { read }; tom

3 4

Bug in audit2allow?
by Cream 17 Sep '04

17 Sep '04

I think i found a bug in audit2allow, when parsing this line: Sep 15 21:10:45 DONut kernel: audit(1095275445.237:0): avc: denied { write } for pid=3463 exe=/usr/sbin/httpd path=/home/iced/www/thumbs/albums/Iced does Greece/parga2003-1 019.jpg dev=hda2 ino=1459429 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_user_content_t tclass=file (running in permissive mode) it turns it into this: allow httpd_t httpd_user_content_t:dir { add_name create write }; #EXE=/usr/sbin/httpd NAME=albums : write #EXE=/usr/sbin/httpd NAME=Iced : add_name #EXE=/usr/sbin/httpd NAME=Iced : create #EXE=/usr/sbin/httpd NAME=Iced : write #EXE=/usr/sbin/httpd NAME=parga2003-1 : add_name as you can see the spaces in the dir name seems to cause problems.

1 0

haldaemon, run_init
by Tom London 16 Sep '04

16 Sep '04

Running strict/enforcing w/ latest from Dan's tree. When haldaemon starts: Sep 16 07:52:29 fedora haldaemon: haldaemon startup succeeded Sep 16 07:52:30 fedora fstab-sync[3132]: removed all generated mount points Sep 16 07:52:30 fedora kernel: audit(1095346350.044:0): avc: denied { execute } for pid=3134 exe=/usr/sbin/hald name=bash dev=hda2 ino=229395 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:shell_exec_t tclass=file Sep 16 07:52:30 fedora mdmonitor: mdadm startup succeeded Believe the AVC is generated when hald tries to run hal_lpadmin from /etc/hal/device.d/printer_remove.hal When I put system into permissive mode and restart haldaemon, I get (sorry for running this as root, but run_init seems busted: Sep 16 11:03:12 fedora kernel: audit(1095357792.163:0): avc: denied { use } for pid=4262 exe=/usr/sbin/run_init path=/dev/pts/2 dev=devpts ino=4 scontext=root:sysadm_r:run_init_t tcontext=user_u:user_r:user_t tclass=fd Sep 16 11:03:12 fedora last message repeated 2 times Sep 16 11:03:12 fedora run_init(pam_unix)[4262]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=root ) Here are the permissive AVCs: Sep 16 10:44:43 fedora kernel: audit(1095356683.853:0): avc: denied { relabelfrom } for pid=8333 exe=/usr/sbin/fstab-sync name=fstab dev=hda2 ino=4475247 scontext=root:system_r:updfstab_t tcontext=root:object_r:etc_t tclass=file Sep 16 10:44:43 fedora kernel: audit(1095356683.854:0): avc: denied { relabelto } for pid=8333 exe=/usr/sbin/fstab-sync name=fstab dev=hda2 ino=4475247 scontext=root:system_r:updfstab_t tcontext=system_u:object_r:etc_t tclass=file Sep 16 10:44:43 fedora fstab-sync[8333]: removed all generated mount points Sep 16 10:44:43 fedora kernel: audit(1095356683.893:0): avc: denied { execute } for pid=8335 exe=/usr/sbin/hald name=bash dev=hda2 ino=229395 scontext=root:system_r:hald_t tcontext=system_u:object_r:shell_exec_t tclass=file Sep 16 10:44:43 fedora kernel: audit(1095356683.894:0): avc: denied { read } for pid=8335 exe=/usr/sbin/hald path=/bin/bash dev=hda2 ino=229395 scontext=root:system_r:hald_t tcontext=system_u:object_r:shell_exec_t tclass=file Sep 16 10:44:43 fedora kernel: audit(1095356683.899:0): avc: denied { execute } for pid=8336 exe=/bin/bash name=hal_lpadmin dev=hda2 ino=278545 scontext=root:system_r:hald_t tcontext=system_u:object_r:sbin_t tclass=file Sep 16 10:44:43 fedora kernel: audit(1095356683.900:0): avc: denied { execute_no_trans } for pid=8336 exe=/bin/bash path=/usr/sbin/hal_lpadmin dev=hda2 ino=278545 scontext=root:system_r:hald_t tcontext=system_u:object_r:sbin_t tclass=file Sep 16 10:44:43 fedora kernel: audit(1095356683.900:0): avc: denied { read } for pid=8336 exe=/bin/bash path=/usr/sbin/hal_lpadmin dev=hda2 ino=278545 scontext=root:system_r:hald_t tcontext=system_u:object_r:sbin_t tclass=file Sep 16 10:44:44 fedora kernel: audit(1095356684.672:0): avc: denied { search } for pid=8381 exe=/usr/libexec/hal-hotplug-map name=hotplug dev=hda2 ino=4472955 scontext=root:system_r:hald_t tcontext=system_u:object_r:hotplug_etc_t tclass=dir Sep 16 10:44:44 fedora kernel: audit(1095356684.674:0): avc: denied { read } for pid=8381 exe=/usr/libexec/hal-hotplug-map name=usb.usermap dev=hda2 ino=4474609 scontext=root:system_r:hald_t tcontext=system_u:object_r:hotplug_etc_t tclass=file Sep 16 10:44:44 fedora kernel: audit(1095356684.674:0): avc: denied { getattr } for pid=8381 exe=/usr/libexec/hal-hotplug-map path=/etc/hotplug/usb.usermap dev=hda2 ino=4474609 scontext=root:system_r:hald_t tcontext=system_u:object_r:hotplug_etc_t tclass=file Sep 16 10:44:45 fedora kernel: audit(1095356685.450:0): avc: denied { use } for pid=8430 exe=/bin/mount path=pipe:[13184] dev=pipefs ino=13184 scontext=user_u:user_r:user_mount_t tcontext=system_u:system_r:xdm_t tclass=fd Sep 16 10:44:45 fedora kernel: audit(1095356685.450:0): avc: denied { write } for pid=8430 exe=/bin/mount path=pipe:[13184] dev=pipefs ino=13184 scontext=user_u:user_r:user_mount_t tcontext=system_u:system_r:xdm_t tclass=fifo_file Sep 16 10:44:46 fedora kernel: audit(1095356686.042:0): avc: denied { execute } for pid=8330 exe=/usr/sbin/hald name=printer_update.hal dev=hda2 ino=280646 scontext=root:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=file Sep 16 10:44:46 fedora kernel: audit(1095356686.075:0): avc: denied { read write } for pid=8330 exe=/usr/sbin/hald name=lp0 dev=tmpfs ino=6883 scontext=root:system_r:hald_t tcontext=system_u:object_r:printer_device_t tclass=chr_file Sep 16 10:44:46 fedora kernel: audit(1095356686.121:0): avc: denied { execute_no_trans } for pid=8479 exe=/usr/sbin/hald path=/etc/hal/capability.d/printer_update.hal dev=hda2 ino=280646 scontext=root:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=file Sep 16 10:44:46 fedora kernel: audit(1095356686.140:0): avc: denied { ioctl } for pid=8479 exe=/bin/bash path=/etc/hal/capability.d/printer_update.hal dev=hda2 ino=280646 scontext=root:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=file

1 0

Problems with NFS
by Christopher R. Swope 16 Sep '04

16 Sep '04

Hi all, I have a little linux box which I pretty much use as a firewall box. I also use it as a server, because I have too many hard drives. I just enabled SELinux on it, using the instructions found on the Fedora page. Most things went fine, but I am having some trouble using files that I export over NFS. The directory at issue is a directory that I use for development (for homework). I have regular executable files (that are compiled from C++ source code), and perl scripts in this directory. I can't run either, as I get a permission denied error message. I tried to do the relabeling thing, and also deleting the files and rebuilding them, but to no avail. I know nothing about SELinux other than what I read on the Fedora page. Can someone please tell me how to fix this problem? Thanks, Christopher

2 1

firefox and /usr/tmp
by Tom London 14 Sep '04

14 Sep '04

When firefox starts it seems to access /usr/tmp: Sep 14 09:35:49 fedora kernel: audit(1095179749.095:0): avc: denied { read } for pid=4728 exe=/usr/lib/firefox-0.9.3/firefox-bin name=tmp dev=hda2 ino=4112460 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:tmp_t tclass=lnk_file donaudit, e.g.? dontaudit $1_mozilla_t tmp_t:lnk_file read; -- Tom London

1 0

dumb question / idea
by josh baverstock 14 Sep '04

14 Sep '04

I must first admit that I am new to linux, I am not qualified to suggest a feature, so please consider this a question. IF its true that when SELinux is fully enabled the restrictions can cause some problems when programs do things they are supposed to do but normally don't, THEN I have an idea. What if an intrusion detection system were to inform the SELinux server that an intrusion is likely happening, which triggers a change from non-enforcement mode to enforcement mode? Would this "raise the shields" method be useful for situations where enforcement mode just isnt right, or is this more of a fundamental misunderstanding on my part of how SELinux works...? I think in the future this NSA project will be an example of the government receiving a 100 fold return on their investment, even considering that SELinux isn't likely to be used in classified systems. _________________________________________________________________ Check out Election 2004 for up-to-date election news, plus voter tools and more! http://special.msn.com/msn/election2004.armx

2 1

SELinux Enabled - Can't mount SMB shares
by Vamsee Krishna Gomatam 13 Sep '04

13 Sep '04

Hello, I've enabled SELinux on my machine running FC2. Everything went well and I didn't get any "avc: denied" messages after I did a "relabel" and reboot. But now, I can't mount any SMB shares. I'm able to give the login and password for mounting and it seems to work. But then, I can't access those mounted drives. What is going wrong? This is my first time with SELinux. regards, GVK -- Real programmers don't work 9 to 5. If any real programmers are around at 9, it's because they were up all night

2 2

tmpfs /dev
by Russell Coker 11 Sep '04

11 Sep '04

I have got a working system with tmpfs /dev and with udev in the initrd. I modified /sbin/init to run the following script immediately after loading the policy: #!/bin/sh . /etc/selinux/config /sbin/setfiles-mine /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts /dev Naturally we need to change the location of setfiles to /sbin from /usr/sbin if this is the solution we choose as this script will run before any file systems are mounted. Below is the policy I added. I had already changed the type declarations to use the dev_filesystem attribute for everything that may occur under /dev (patch sent to the main SE Linux list). I have setfiles being run as kernel_t because I feel that running setfiles as kernel_t is better than granting setfiles_t more access than is otherwise required. This means that I have to grant kernel_t access to relabel the device nodes, no big deal IMHO as kernel_t generally has ultimate access anyway. I relabeled /sbin/MAKEDEV as udev_exec_t so that it runs as udev_t when run from /sbin/start_udev and can do the things that it wants to do. This is a minor hack. Maybe it would be better to label /sbin/start_udev as udev_exec_t? That would remove the need to allow initrc_t to create sym-links under /dev. avc: denied { getattr } for pid=1641 exe=/sbin/lvm.static path=/sbin/MAKEDEV dev=dm-0 ino=196261 scontext=system_u:system_r:lvm_t tcontext=system_u:object_r:udev_exec_t tclass=file Why does lvm.static want to stat /sbin/MAKEDEV? Seems strange to me. Below is the policy I wrote to allow tmpfs /dev and udev in initrd. I haven't split it into all the relevant .te files because it's still an experiment at this stage. After some discussion I'll produce a release version. # for tmpfs /dev allow dev_filesystem tmpfs_t:filesystem associate; allow kernel_t tmpfs_t:chr_file rw_file_perms; allow kernel_t tmpfs_t:{ dir file lnk_file chr_file blk_file } { getattr relabel from }; allow kernel_t device_t:{ dir lnk_file chr_file blk_file } relabelto; allow kernel_t device_type:{ chr_file blk_file } relabelto; allow kernel_t udev_tbl_t:file relabelto; can_exec(kernel_t, { sbin_t setfiles_exec_t }) # for /dev/pts on tmpfs allow mount_t tmpfs_t:dir mounton; # for /sbin/MAKEDEV - why? allow lvm_t udev_exec_t:file getattr; # allow /sbin/start_udev to run ln allow initrc_t device_t:lnk_file create_lnk_perms; -- 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

4 5

/etc/hal/capability.d/printer_update.hal
by Tom London 10 Sep '04

10 Sep '04

Notice the following: Sep 9 09:37:55 fedora kernel: audit(1094747875.090:0): avc: denied { execute } for pid=3131 exe=/usr/sbin/hald name=printer_update.hal dev=hda2 ino=280646 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=file Sep 9 09:37:55 fedora kernel: audit(1094747875.090:0): avc: denied { execute } for pid=3131 exe=/usr/sbin/hald name=printer_update.hal dev=hda2 ino=280646 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=file Should the following be added to hald.fc? /etc/hal/capability.d/printer_update.hal -- system_u:object_r:hald_exec_t (similar to /etc/hal/device.d/printer_remove.hal ?) tom -- Tom London

1 0

relabeling cycles...
by Tom London 09 Sep '04

09 Sep '04

No matter how often I 'fix' these files with either setfiles or fixfiles, they seem to revert back the next reboot. I think I've also booted single-user to do relabeling with the same effect. Not clear this affects functioning in any way. tom > /usr/sbin/setfiles: relabeling /var/run/saslauthd/mux.accept from > system_u:object_r:saslauthd_var_run_t to system_u:object_r:var_run_t > /usr/sbin/setfiles: relabeling /var/run/saslauthd/mux from > system_u:object_r:saslauthd_var_run_t to system_u:object_r:var_run_t > /usr/sbin/setfiles: relabeling /tmp/.X11-unix from > system_u:object_r:xdm_tmp_t > to system_u:object_r:xdm_xserver_tmp_t > /usr/sbin/setfiles: relabeling /tmp/.X0-lock from > system_u:object_r:xdm_xserver_tmp_t to system_u:object_r:xdm_tmp_t

2 1

latest Rawhide... selinux-policy-strict-1.17.9-2
by Tom London 09 Sep '04

09 Sep '04

Newest Rawhide packages improve things a bit for strict/enforcing, but still no joy. When booting strict/enforcing, the system seems to boot to single user mode, but is unable to write to the console. Last messages are avc denials from /bin/dmesg, that seem to occur just before the 'Welcome to Fedora' message. I can hear the device discovery going on, but nothing on the console. After about 5 minutes, ALT-CTL-DEL brought the system down, with the customary console messages. (But, error messages about most file systems not being mounted). Here are the early avcs... Sep 3 07:25:35 fedora kernel: audit(1094196259.050:0): avc: denied { create } for pid=1 exe=/sbin/init name=initctl scontext=system_u:system_r:init_t tcontext=system_u:object_r:unlabeled_t tclass=fifo_file Sep 3 07:25:36 fedora smartd[2856]: Opened configuration file /etc/smartd.conf Sep 3 07:25:36 fedora kernel: audit(1094196259.050:0): avc: denied { associate } for pid=1 exe=/sbin/init name=initctl scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:fs_t tclass=filesystem Sep 3 07:25:36 fedora smartd[2856]: Configuration file /etc/smartd.conf parsed. Sep 3 07:25:36 fedora kernel: audit(1094196259.050:0): avc: denied { read write } for pid=1 exe=/sbin/init name=initctl dev=tmpfs ino=2095 scontext=system_u:system_r:init_t tcontext=system_u:object_r:unlabeled_t tclass=fifo_file Sep 3 07:25:36 fedora smartd[2856]: Device: /dev/hda, opened Sep 3 07:25:36 fedora kernel: audit(1094196259.050:0): avc: denied { getattr } for pid=1 exe=/sbin/init path=/dev/initctl dev=tmpfs ino=2095 scontext=system_u:system_r:init_t tcontext=system_u:object_r:unlabeled_t tclass=fifo_file Sep 3 07:25:36 fedora smartd[2856]: Device: /dev/hda, found in smartd database. Sep 3 07:25:36 fedora kernel: audit(1094196259.312:0): avc: denied { read write } for pid=344 exe=/bin/hostname name=console dev=tmpfs ino=864 scontext=system_u:system_r:hostname_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:36 fedora kernel: audit(1094196259.382:0): avc: denied { search } for pid=346 exe=/bin/bash dev=tmpfs ino=863 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:unlabeled_t tclass=dir Sep 3 07:25:36 fedora kernel: audit(1094196259.382:0): avc: denied { read write } for pid=346 exe=/bin/bash name=tty dev=tmpfs ino=1227 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:37 fedora smartd[2856]: Device: /dev/hda, is SMART capable. Adding to "monitor" list. Sep 3 07:25:37 fedora kernel: audit(1094196260.276:0): avc: denied { read write } for pid=490 exe=/bin/mount name=console dev=tmpfs ino=864 scontext=system_u:system_r:mount_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:37 fedora smartd[2856]: Monitoring 1 ATA and 0 SCSI devices Sep 3 07:25:37 fedora kernel: audit(1094196260.277:0): avc: denied { search } for pid=490 exe=/bin/mount dev=tmpfs ino=863 scontext=system_u:system_r:mount_t tcontext=system_u:object_r:unlabeled_t tclass=dir Sep 3 07:25:37 fedora kernel: SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts Sep 3 07:25:38 fedora smartd[2858]: smartd has fork()ed into background mode. New PID=2858. Sep 3 07:25:38 fedora kernel: audit(1094196260.368:0): avc: denied { read write } for pid=514 exe=/sbin/consoletype name=console dev=tmpfs ino=864 scontext=system_u:system_r:consoletype_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:38 fedora smartd: smartd startup succeeded Sep 3 07:25:38 fedora kernel: audit(1094196260.368:0): avc: denied { getattr } for pid=514 exe=/sbin/consoletype path=/dev/console dev=tmpfs ino=864 scontext=system_u:system_r:consoletype_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:38 fedora kernel: audit(1094196260.368:0): avc: denied { ioctl } for pid=514 exe=/sbin/consoletype path=/dev/console dev=tmpfs ino=864 scontext=system_u:system_r:consoletype_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:38 fedora kernel: audit(1094196262.158:0): avc: denied { read write } for pid=724 exe=/sbin/minilogd name=console dev=tmpfs ino=864 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:38 fedora kernel: audit(1094196262.158:0): avc: denied { use } for pid=724 exe=/sbin/minilogd path=/init dev=rootfs ino=17 scontext=system_u:system_r:syslogd_t tcontext=system_u:system_r:kernel_t tclass=fd Sep 3 07:25:38 fedora kernel: audit(1094196262.158:0): avc: denied { read } for pid=724 exe=/sbin/minilogd path=/init dev=rootfs ino=17 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Sep 3 07:25:38 fedora kernel: audit(1094196262.159:0): avc: denied { search } for pid=724 exe=/sbin/minilogd dev=tmpfs ino=863 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:unlabeled_t tclass=dir Sep 3 07:25:38 fedora kernel: audit(1094196262.159:0): avc: denied { write } for pid=724 exe=/sbin/minilogd dev=tmpfs ino=863 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:unlabeled_t tclass=dir Sep 3 07:25:38 fedora kernel: audit(1094196262.159:0): avc: denied { add_name } for pid=724 exe=/sbin/minilogd name=log scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:unlabeled_t tclass=dir Sep 3 07:25:38 fedora kernel: audit(1094196262.159:0): avc: denied { create } for pid=724 exe=/sbin/minilogd name=log scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:unlabeled_t tclass=sock_file Sep 3 07:25:38 fedora kernel: audit(1094196262.160:0): avc: denied { getattr } for pid=727 exe=/sbin/minilogd path=/dev/log dev=tmpfs ino=2641 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:unlabeled_t tclass=sock_file Sep 3 07:25:38 fedora kernel: audit(1094196262.217:0): avc: denied { read write } for pid=730 exe=/bin/dmesg name=console dev=tmpfs ino=864 scontext=system_u:system_r:dmesg_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:38 fedora acpid: acpid startup succeeded Sep 3 07:25:38 fedora kernel: audit(1094196262.285:0): avc: denied { read write } for pid=735 exe=/sbin/restorecon name=console dev=tmpfs ino=864 scontext=system_u:system_r:restorecon_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:38 fedora kernel: audit(1094196266.948:0): avc: denied { create } for pid=746 exe=/sbin/udev name=input scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=dir tom

4 3

[idea] udev + selinux
by Nigel Kukard 08 Sep '04

08 Sep '04

Just an idea, but why not have udev set the context on its root path? I have a simplistic patch for this if its a good idea. Regards Nigel Kukard

12 29

SELinux article in eWeek
by Frank Mayer 07 Sep '04

07 Sep '04

Not a depth article but generally favorable review of SELinux: http://www.eweek.com/article2/0,1759,1643024,00.asp Frank

1 0

RE: Users writting to home directory
by Don Patterson 07 Sep '04

07 Sep '04

> ----- Original Message ----- > From: "James R. Marcus" <jmarcus(a)mvalent.net> > To: "Stephen Smalley" <sds(a)epoch.ncsc.mil> > Cc: <selinux(a)tycho.nsa.gov> > Sent: Tuesday, August 24, 2004 2:14 PM > Subject: RE: Users writting to home directory > > > > Okay I tried just creating a user under home. While in permissive > > mode they can login to the ftp server and upload and download. > > However when I turn on enforced mode they get this message: > > > > C:\Documents and Settings\jmarcus\Desktop>ftp ftp Connected to > > ftp.mvalent.local. > > 220 Welcome to mValent, Inc. FTP service. > > User (ftp.mvalent.local:(none)): jmarcus7 > > 331 Please specify the password. > > Password: > > 500 OOPS: cannot change directory:/home/jmarcus7 500 OOPS: child > > died Connection closed by remote host. > > > > C:\Documents and Settings\jmarcus\Desktop> > > > > ftp policy # seuseradd -g users -d /home/jmarcus7 -m -s /bin/bash > > -c "James R. Marcus" jmarcus7 loading new policy... > > > > Error relabeling users home directory files: User is not defined in > > the policy. > > > In case anyone sees a similar problem, this bug was fixed in setools 1.4.x. To upgrade use the commands: Fedora - 'yum update setools' Gentoo - 'emerge setools' Don Patterson Tresys Technology www.tresys.com

1 0

(no subject)
by Frank Mayer 07 Sep '04

07 Sep '04

CALL FOR PRESENTATION PROPOSALS FIRST SECURITY ENHANCED LINUX SYMPOSIUM (www.selinux-symposium.org) The inaugural symposium on Security Enhanced Linux (SELinux) will be held March 2-4 2005 in the Silver Spring, Maryland, USA (near Washington, DC). SELinux brings the power of flexible mandatory access control such as type enforcement to Linux. The symposium is an opportunity to learn about SELinux and share technical and application experiences. The call for presentation and tutorial proposals is now open until October 1, 2004. All proposals will be reviewed by the review committees for inclusion in the symposium agenda. To submit proposals visit http://www.selinux-symposium.org.

1 0

Re: fedora-selinux-list Digest, Vol 7, Issue 1
by Stanley A. Klein 07 Sep '04

07 Sep '04

On Wed, 2004-09-01 at 12:00, Linas Vepstas <linas(a)austin.ibm.com> wrote: > > Every now and then, I look at SELinux, and I get scared away by its > complexity. This complexity makes it very hard to audit, and assure > oneself that its actually providing any real security, as opposed to > the illusion of security. During this email thread, there are > references to mysterious rules that neither party in the conversation > fully understands; this scares me. > This is not the first time I've heard about SELinux complexity. A colleague attended a meeting of the DC area SELinux Users Group and came away repeating stories about 50000 rules that needed to be defined for a typical system. His reaction was "How can you be sure you have done 50000 rules right?". I heard similar talk in the hallway at one of the EGOVOS conferences. I think the complexity derives from Mandatory Access Control rather than SELinux itself. Thus far almost all of the attention regarding SELinux policies has been given to basic computer infrastructure and basic system administration. Some of the packages in the basic infrastructure have hundreds of files. MAC requires each file in each package to be considered and its access control rules defined. The complexity in the rules is a consequence of the complexity in the infrastructure. The real issue is the adequacy of tools to manage the complexity. Furthermore, although SELinux has the mechanisms for defining and enforcing access control rules beyond the basic infrastructure, trying to develop policies based on business process rules and business considerations looks like a daunting task right now. By this I mean roles that get beyond sysadmin and user into areas such as bank teller or hospital primary care provider or control system operations shift supervisor, together with the rules appropriate to those roles in their business contexts. I think there are people working on tool concepts, but it seems we are a few years away from taming the complexity of MAC and SELinux sufficiently to allow users to easily and confidently define SELinux policies for applications based on business considerations. Stan Klein -- Stanley A. Klein, D.Sc. Principal Consultant Stan Klein Associates, LLC 301-881-4087

2 1

Re: log file names (was Additional rule files)
by Russell Coker 05 Sep '04

05 Sep '04

On Sat, 4 Sep 2004 11:12, Erich Schubert <erich(a)debian.org> wrote: > The next two rule sets are for the statistic tools "bindgraph" and > "mailgraph". The first parses bind query logs and does nice graphs out > of them, the second does the same for postfix+amavis logs. Do we need to have two different domains for programs that do the same thing? Both bindgraph and mailgraph can read the same file types as input and their output can be accessed by cgi-bin scripts. It seems that there is little (if any) benefit in isolating them. If we were to assign different types to different log files (may require code changes in syslogd) then we could deny the mailgraph program the ability to read log files other than mail.log and deny the bindgraph program the ability to read mail.log. Also note that in your policy both those programs can read /var/log/auth.log (Debian) and /var/log/secure (Fedora). This is not desirable, we probably should make changes to the syslog setup. One possible change is greater use of sub-directories in /var/log. We could have /var/log/security/ for auth.log, secure, and any other security critical log files and /var/log/mail/ for mail server log files (including POP server, and maybe webmail), etc. Doing this would allow different types for the log files with no code changes to syslogd, and this would make it more beneficial to have separate domains for mailgraph and bindgraph. I've CC'd this to fedora-selinux and debian-devel because if we make such changes then we want to get some cross-distribution agreement on file names. -- 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

2 2

Wiped installation - 541 kernel - SELinux cleared?
by Jim Cornette 05 Sep '04

05 Sep '04

After viewing the logs myself, I think that SELinux was working properly. I deleted the installation and am using it as a clean download partition for the FC3T2 iso files. It looks like SELInux is working pretty decent up until gawk, the latest kernel, etc: Jim -- You're at the end of the road again.

1 0

Kernel *-541 - avc errors - ... after fsck,reboot,fixfiles,reboot
by Jim Cornette 05 Sep '04

05 Sep '04

When I booted up with the latest development kernel -541, I got the following avc errors. Also, I ended up damaging my installation. The first attached file is from the first boot and encountering errors. I'll send a second message with the after relabeling filesystem errors. Here is the second avc error file. The system was fscked to eliminate errors. (Also was dropped to init 1 because of file errors) Bad inodes were detected, so I rebooted and did fixfiles relabel. After that, I rebooted and logged in again. X would not startup, it hung at switching to graphics and could not event be pinged from another computer on my network. (Locked up, I presume.) Jim Aug 29 10:19:14 localhost dbus: avc: 2 AV entries and 2/512 buckets used, longest chain length 1 Aug 29 13:34:01 localhost kernel: audit(1093800840.407:0): avc: denied { name_bind } for pid=2896 exe=/sbin/portmap scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:rndc_port_t tclass=tcp_socket Aug 29 15:59:39 localhost kernel: audit(1093795091.123:0): avc: denied { read } for pid=540 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093795108.860:0): avc: denied { read } for pid=981 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093795111.616:0): avc: denied { read } for pid=1061 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093795111.623:0): avc: denied { read } for pid=1085 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: uba:<3>audit(1093795111.668:0): avc: denied { read } for pid=1094 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093795111.733:0): avc: denied { read } for pid=1095 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093795111.777:0): avc: denied { read } for pid=1097 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809513.654:0): avc: denied { read } for pid=1276 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809513.657:0): avc: denied { read } for pid=1277 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809514.672:0): avc: denied { read } for pid=1334 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809515.563:0): avc: denied { read } for pid=1379 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809521.168:0): avc: denied { read } for pid=1398 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809521.187:0): avc: denied { read } for pid=1403 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809521.553:0): avc: denied { read } for pid=1409 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809538.678:0): avc: denied { read } for pid=2075 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809542.585:0): avc: denied { read } for pid=2097 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809546.717:0): avc: denied { read } for pid=2460 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809549.895:0): avc: denied { read } for pid=2464 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809567.142:0): avc: denied { read } for pid=2667 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:12:07 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Aug 29 16:14:38 localhost kernel: audit(1093795992.389:0): avc: denied { read } for pid=558 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093796009.505:0): avc: denied { read } for pid=852 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: uba:<3>audit(1093796012.291:0): avc: denied { read } for pid=944 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093796012.295:0): avc: denied { read } for pid=945 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093796012.298:0): avc: denied { read } for pid=946 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093796012.300:0): avc: denied { read } for pid=947 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093796012.310:0): avc: denied { read } for pid=949 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810411.029:0): avc: denied { read } for pid=962 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810411.033:0): avc: denied { read } for pid=963 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810413.351:0): avc: denied { read } for pid=1062 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810413.369:0): avc: denied { read } for pid=1066 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810415.423:0): avc: denied { read } for pid=1135 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810415.433:0): avc: denied { read } for pid=1137 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810416.925:0): avc: denied { read } for pid=1145 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810432.496:0): avc: denied { read } for pid=1647 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810436.371:0): avc: denied { read } for pid=1668 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810440.677:0): avc: denied { read } for pid=2031 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810460.930:0): avc: denied { read } for pid=2224 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810463.417:0): avc: denied { read } for pid=2274 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810477.009:0): avc: denied { read } for pid=2634 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 23:10:57 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Aug 30 07:48:10 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Aug 30 19:46:33 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Aug 30 19:49:05 localhost kernel: audit(1093895257.851:0): avc: denied { read } for pid=564 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093895275.011:0): avc: denied { read } for pid=858 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093895277.661:0): avc: denied { read } for pid=943 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093895277.665:0): avc: denied { read } for pid=944 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093895277.668:0): avc: denied { read } for pid=945 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: uba:<3>audit(1093895277.770:0): avc: denied { read } for pid=953 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093895277.780:0): avc: denied { read } for pid=955 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909680.749:0): avc: denied { read } for pid=1046 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909680.752:0): avc: denied { read } for pid=1047 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909681.408:0): avc: denied { read } for pid=1072 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909681.417:0): avc: denied { read } for pid=1074 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909683.430:0): avc: denied { read } for pid=1137 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909683.448:0): avc: denied { read } for pid=1142 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909684.958:0): avc: denied { read } for pid=1152 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909700.061:0): avc: denied { read } for pid=1654 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909704.006:0): avc: denied { read } for pid=1675 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909708.395:0): avc: denied { read } for pid=2039 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909716.420:0): avc: denied { read } for pid=2134 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909728.426:0): avc: denied { read } for pid=2231 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909731.223:0): avc: denied { read } for pid=2282 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909744.003:0): avc: denied { read } for pid=2641 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:55:30 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Aug 30 21:17:19 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Sep 1 21:03:06 localhost kernel: audit(1094086986.820:0): avc: granted { load_policy } for pid=12264 exe=/usr/sbin/load_policy scontext=root:system_r:unconfined_t tcontext=system_u:object_r:security_t tclass=security Sep 1 21:05:34 localhost dbus: avc: received policyload notice (seqno=1) Sep 1 21:05:34 localhost dbus: avc: 3 AV entries and 3/512 buckets used, longest chain length 1 Sep 2 07:39:47 localhost dbus: avc: 3 AV entries and 3/512 buckets used, longest chain length 1 Sep 2 17:43:32 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Sep 2 19:40:55 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Sep 4 21:15:57 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1

1 0

Kernel *-541 - avc errors - busts inodes - kills X11
by Jim Cornette 05 Sep '04

05 Sep '04

When I booted up with the latest development kernel -541, I got the following avc errors. Also, I ended up damaging my installation. The first attached file is from the first boot and encountering errors. I'll send a second message with the after relabeling filesystem errors. Here is the first boot avc errors file from initial boot. mode is enforcing/targeted Jim -- You're at the end of the road again. Aug 29 10:19:14 localhost dbus: avc: 2 AV entries and 2/512 buckets used, longest chain length 1 Aug 29 13:34:01 localhost kernel: audit(1093800840.407:0): avc: denied { name_bind } for pid=2896 exe=/sbin/portmap scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:rndc_port_t tclass=tcp_socket Aug 29 15:59:39 localhost kernel: audit(1093795091.123:0): avc: denied { read } for pid=540 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093795108.860:0): avc: denied { read } for pid=981 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093795111.616:0): avc: denied { read } for pid=1061 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093795111.623:0): avc: denied { read } for pid=1085 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: uba:<3>audit(1093795111.668:0): avc: denied { read } for pid=1094 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093795111.733:0): avc: denied { read } for pid=1095 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093795111.777:0): avc: denied { read } for pid=1097 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809513.654:0): avc: denied { read } for pid=1276 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809513.657:0): avc: denied { read } for pid=1277 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809514.672:0): avc: denied { read } for pid=1334 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809515.563:0): avc: denied { read } for pid=1379 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809521.168:0): avc: denied { read } for pid=1398 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809521.187:0): avc: denied { read } for pid=1403 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809521.553:0): avc: denied { read } for pid=1409 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809538.678:0): avc: denied { read } for pid=2075 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809542.585:0): avc: denied { read } for pid=2097 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809546.717:0): avc: denied { read } for pid=2460 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809549.895:0): avc: denied { read } for pid=2464 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 15:59:39 localhost kernel: audit(1093809567.142:0): avc: denied { read } for pid=2667 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:12:07 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Aug 29 16:14:38 localhost kernel: audit(1093795992.389:0): avc: denied { read } for pid=558 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093796009.505:0): avc: denied { read } for pid=852 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: uba:<3>audit(1093796012.291:0): avc: denied { read } for pid=944 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093796012.295:0): avc: denied { read } for pid=945 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093796012.298:0): avc: denied { read } for pid=946 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093796012.300:0): avc: denied { read } for pid=947 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093796012.310:0): avc: denied { read } for pid=949 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810411.029:0): avc: denied { read } for pid=962 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810411.033:0): avc: denied { read } for pid=963 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810413.351:0): avc: denied { read } for pid=1062 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810413.369:0): avc: denied { read } for pid=1066 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810415.423:0): avc: denied { read } for pid=1135 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810415.433:0): avc: denied { read } for pid=1137 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810416.925:0): avc: denied { read } for pid=1145 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810432.496:0): avc: denied { read } for pid=1647 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810436.371:0): avc: denied { read } for pid=1668 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810440.677:0): avc: denied { read } for pid=2031 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810460.930:0): avc: denied { read } for pid=2224 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810463.417:0): avc: denied { read } for pid=2274 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 16:14:38 localhost kernel: audit(1093810477.009:0): avc: denied { read } for pid=2634 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 29 23:10:57 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Aug 30 07:48:10 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Aug 30 19:46:33 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Aug 30 19:49:05 localhost kernel: audit(1093895257.851:0): avc: denied { read } for pid=564 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093895275.011:0): avc: denied { read } for pid=858 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093895277.661:0): avc: denied { read } for pid=943 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093895277.665:0): avc: denied { read } for pid=944 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093895277.668:0): avc: denied { read } for pid=945 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: uba:<3>audit(1093895277.770:0): avc: denied { read } for pid=953 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093895277.780:0): avc: denied { read } for pid=955 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909680.749:0): avc: denied { read } for pid=1046 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909680.752:0): avc: denied { read } for pid=1047 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909681.408:0): avc: denied { read } for pid=1072 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909681.417:0): avc: denied { read } for pid=1074 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909683.430:0): avc: denied { read } for pid=1137 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909683.448:0): avc: denied { read } for pid=1142 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909684.958:0): avc: denied { read } for pid=1152 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909700.061:0): avc: denied { read } for pid=1654 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909704.006:0): avc: denied { read } for pid=1675 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909708.395:0): avc: denied { read } for pid=2039 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909716.420:0): avc: denied { read } for pid=2134 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909728.426:0): avc: denied { read } for pid=2231 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909731.223:0): avc: denied { read } for pid=2282 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:49:05 localhost kernel: audit(1093909744.003:0): avc: denied { read } for pid=2641 exe=/sbin/minilogd path=/init dev=rootfs ino=27 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Aug 30 19:55:30 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Aug 30 21:17:19 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Sep 1 21:03:06 localhost kernel: audit(1094086986.820:0): avc: granted { load_policy } for pid=12264 exe=/usr/sbin/load_policy scontext=root:system_r:unconfined_t tcontext=system_u:object_r:security_t tclass=security Sep 1 21:05:34 localhost dbus: avc: received policyload notice (seqno=1) Sep 1 21:05:34 localhost dbus: avc: 3 AV entries and 3/512 buckets used, longest chain length 1 Sep 2 07:39:47 localhost dbus: avc: 3 AV entries and 3/512 buckets used, longest chain length 1 Sep 2 17:43:32 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Sep 2 19:40:55 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1

1 0

Todays issues with strict policy
by Leonard den Ottolander 03 Sep '04

03 Sep '04

Hi, Noticed a lot of issues with selinux-policy-strict-1.17.8-2 today: Loads of udev related avc denies: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130992 (old bug, new messages) Smartd fails to start: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131696 eth0 doesn't come up at system startup: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131698 Can't login to X because dbus policy incorrect/incomplete: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131701 Leonard. -- mount -t life -o ro /dev/dna /genetic/research

1 0

.541 status.... invalid context
by Tom London 03 Sep '04

03 Sep '04

Running strict, with latest from Rawhide (except gawk), with selinux-policy-strict-1.17.8-2. After backing out gawk and reinstalling .541, I have a system that boots, but only in permissive mode. In strict mode, many avc's rush past, and then the systems automagically reboots before I have time to examine the screen (nothing makes it to the log). Booting in permissive mode produces scads of avc's. I notice the following on 'make reload' of the policy: Sep 2 20:26:29 fedora kernel: security: 4 users, 6 roles, 1220 types, 23 bools Sep 2 20:26:29 fedora kernel: security: 53 classes, 278677 rules Sep 2 20:26:29 fedora kernel: security: context user_u:user_r:dbusd_t is invalid checkpolicy doesn't seem to complain ..... Anything to worry about? tom

2 1

RAID HPT370 & Linux Fedora Core 2
by DP 02 Sep '04

02 Sep '04

Hi, I have folowing problem: I built RAID1 in HPT370 controller. After boot from installation CD Linux FC2 not visible in system RAID field, but two physical disks. Help me somebody? Thanks DP

1 0

Progress! .532 boots! -- but dbus/hotplug/udev problems remain?
by Tom London 01 Sep '04

01 Sep '04

Newest Rawhide updates (including udev-030-10, mkinitrd-4.1.8-1, kernel-2.6.8-1.532, and selinux-policy-strict-1.17.5-2) now boots in strict/enforcing. Many AVCs, and there is a problem with runlevel 5 (graphical login, etc.) preventing login, (but text login works). Here are the first, early AVCs: (I'll dig for more later.) Aug 28 10:23:40 fedora kernel: usbcore: registered new driver usblp Aug 28 10:23:40 fedora kernel: drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver Aug 28 10:23:40 fedora acpid: acpid startup succeeded Aug 28 10:23:40 fedora kernel: ACPI: Power Button (FF) [PWRF] Aug 28 10:23:40 fedora kernel: ACPI: Sleep Button (CM) [FUTS] Aug 28 10:23:40 fedora kernel: EXT3 FS on hda2, internal journal Aug 28 10:23:41 fedora kernel: audit(1093713783.757:0): avc: denied { search } for pid=1264 exe=/sbin/udev name=contexts dev=hda2 ino=4509745 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:default_context_t tclass=dir Aug 28 10:23:41 fedora kernel: audit(1093713783.790:0): avc: denied { execute_no_trans } for pid=1271 exe=/sbin/udev path=/etc/udev/scripts/pam_console.dev dev=hda2 ino=574019 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Aug 28 10:23:41 fedora kernel: audit(1093713783.790:0): avc: denied { write } for pid=1264 exe=/sbin/udev name=fscreate dev=proc ino=82837526 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=file There repeat many times. When run in permissive mode, this sequence becomes: Aug 28 10:32:25 fedora kernel: EXT3 FS on hda2, internal journal Aug 28 10:32:25 fedora kernel: audit(1093714297.852:0): avc: denied { search } for pid=1283 exe=/sbin/udev name=contexts dev=hda2 ino=4509745 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:default_context_t tclass=dir Aug 28 10:32:25 fedora kernel: audit(1093714297.859:0): avc: denied { search } for pid=1283 exe=/sbin/udev name=files dev=hda2 ino=4509746 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_context_t tclass=dir Aug 28 10:32:25 fedora kernel: audit(1093714297.872:0): avc: denied { read } for pid=1283 exe=/sbin/udev name=file_contexts dev=hda2 ino=4505700 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_context_t tclass=file Aug 28 10:32:25 fedora kernel: audit(1093714297.872:0): avc: denied { getattr } for pid=1283 exe=/sbin/udev path=/etc/selinux/strict/contexts/files/file_contexts dev=hda2 ino=4505700 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_context_t tclass=file Aug 28 10:32:25 fedora kernel: audit(1093714298.077:0): avc: denied { execute_no_trans } for pid=1285 exe=/sbin/udev path=/etc/udev/scripts/pam_console.dev dev=hda2 ino=574019 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Aug 28 10:32:25 fedora kernel: audit(1093714298.109:0): avc: denied { search } for pid=1285 exe=/bin/bash name=console dev=hda2 ino=4456494 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:pam_var_console_t tclass=dir Aug 28 10:32:25 fedora kernel: audit(1093714298.113:0): avc: denied { write } for pid=1283 exe=/sbin/udev name=fscreate dev=proc ino=84082710 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=file Aug 28 10:32:25 fedora kernel: audit(1093714298.113:0): avc: denied { setfscreate } for pid=1283 exe=/sbin/udev scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=process Aug 28 10:32:25 fedora kernel: audit(1093714317.126:0): avc: denied { search } for pid=1671 exe=/sbin/udev name=files dev=hda2 ino=4509746 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_context_t tclass=dir Audit2allow on this says: allow : { write }; allow udev_t default_context_t:dir { search }; allow udev_t etc_t:file { execute_no_trans }; allow udev_t file_context_t:dir { search }; allow udev_t file_context_t:file { read }; allow udev_t pam_var_console_t:dir { search }; allow udev_t udev_t:process { setfscreate }; The funny 'allow : { write };' is for the write of 'fscreate' in /proc. After obtaining the graphical login screen, here is the offending AVC: Aug 28 10:24:42 fedora gdm(pam_unix)[3888]: session opened for user tbl by (uid=0) Aug 28 10:24:43 fedora kernel: audit(1093713883.626:0): avc: denied { create } for pid=4042 exe=/usr/bin/dbus-daemon-1 scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t tclass=netlink_selinux_socket An error window pops up reporting an SELinux/AVC type failure. It then returns to the login screen. Just prior to that, there are many 'denied's from udev and hald. Here are a few: Aug 28 10:24:21 fedora dbus: avc: denied { send_msg } for scontext=system_u:system_r:hald_t tcontext=system_u:system_r:updfstab_t tclass=dbus Aug 28 10:24:21 fedora kernel: audit(1093713853.755:0): avc: denied { execute } for pid=3466 exe=/usr/sbin/hald name=hal-hotplug-map dev=hda2 ino=606213 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:bin_t tclass=file Aug 28 10:24:21 fedora udev[3953]: creating device node '/dev/vcs7' Aug 28 10:24:22 fedora dbus: avc: denied { send_msg } for scontext=system_u:system_r:hald_t tcontext=system_u:system_r:updfstab_t tclass=dbus Aug 28 10:24:22 fedora kernel: audit(1093713853.817:0): avc: denied { search } for pid=3798 exe=/sbin/udev name=contexts dev=hda2 ino=4509745 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:default_context_t tclass=dir Aug 28 10:24:22 fedora dbus: avc: denied { send_msg } for scontext=system_u:system_r:hald_t tcontext=system_u:system_r:updfstab_t tclass=dbus Aug 28 10:24:22 fedora kernel: audit(1093713853.819:0): avc: denied { execute_no_trans } for pid=3846 exe=/sbin/udev path=/etc/udev/scripts/pam_console.dev dev=hda2 ino=574019 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Aug 28 10:24:22 fedora dbus: avc: denied { send_msg } for scontext=system_u:system_r:updfstab_t tcontext=system_u:system_r:hald_t tclass=dbus Aug 28 10:24:22 fedora kernel: audit(1093713853.820:0): avc: denied { write } for pid=3798 exe=/sbin/udev name=fscreate dev=proc ino=248905750 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=file [BTW: When I reboot, /etc/fstab has been relabeled to type tmp_t. Is the above causing this?] I rebooted strict/permissive, and things appear OK, including loading of sound modules. However, as noted above, something is relabeling /etc/fstab to tmp_t: Aug 28 10:33:21 fedora gdm(pam_unix)[3786]: session opened for user tbl by (uid=0) Aug 28 10:33:21 fedora kernel: audit(1093714401.349:0): avc: denied { read } for pid=3786 exe=/usr/bin/gdm-binary name=fstab dev=hda2 ino=4654141 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:tmp_t tclass=file Aug 28 10:33:21 fedora kernel: audit(1093714401.350:0): avc: denied { getattr } for pid=3786 exe=/usr/bin/gdm-binary path=/etc/fstab dev=hda2 ino=4654141 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:tmp_t tclass=file I believe I'm running a 'stock' Rawhide system. tom

7 13

hald/hal-hotplug-map
by Tom London 01 Sep '04

01 Sep '04

hald seems to need to execute /usr/libexec/hal-hotplug-map: Aug 29 12:45:46 fedora kernel: audit(1093808744.270:0): avc: denied { execute } for pid=3436 exe=/usr/sbin/hald name=hal-hotplug-map dev=hda2 ino=4123436 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:bin_t tclass=file Aug 29 12:45:46 fedora kernel: audit(1093808744.284:0): avc: denied { execute } for pid=3436 exe=/usr/sbin/hald name=hal-hotplug-map dev=hda2 ino=4123436 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:bin_t tclass=file Does it make sense to label /usr/libexec/hal* as hald_exec_t and add 'canexec(hald_t, hald_exec_t)' to hald.te ? Also, seems that hald and updfstab need to do their dbus thing, and hald wants to access printer_device_t. Suggested patches to hald.te and hald.fc --- hald.te 2004-08-27 14:37:17.000000000 -0700 +++ /etc/selinux/strict/src.old/policy/domains/program/hald.te 2004-08-28 13:40:57.000000000 -0700 @@ -37,7 +37,12 @@ ifdef(`udev.te', ` domain_auto_trans(hald_t, udev_exec_t, udev_t) allow udev_t hald_t:unix_dgram_socket sendto; +allow hald_t updfstab_t:dbus { send_msg }; +allow updfstab_t hald_t:dbus { send_msg }; ') allow hald_t usbdevfs_t:dir search; allow hald_t usbdevfs_t:file { getattr read }; + +allow hald_t printer_device_t:chr_file { read write }; +can_exec(hald_t, hald_exec_t) --- /etc/selinux/strict/src.old/policy/domains/program/../../file_contexts/program/hald.fc 2004-08-27 14:37:17.000000000 -0700 +++ hald.fc 2004-08-29 13:36:44.147534409 -0700 @@ -1,2 +1,3 @@ # hald - hardware informationd daemon /usr/sbin/hald -- system_u:object_r:hald_exec_t +/usr/libexec/hal-.* -- system_u:object_r:hald_exec_t Please correct/improve, tom tom

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux September 2004