From linux_4ever at yahoo.com Sun Jan 1 14:23:43 2006 From: linux_4ever at yahoo.com (Steve G) Date: Sun, 1 Jan 2006 06:23:43 -0800 (PST) Subject: top avcs Message-ID: <20060101142343.46114.qmail@web51504.mail.yahoo.com> Hi, I was running top as a normal user on my rawhide machine. Its scrolls avcs for various pids like this: type=PATH msg=audit(01/01/2006 08:55:21.980:306) : item=0 name=/proc/425/stat inode=27852814 dev=00:03 mode=file,444 ouid=root ogid=root rdev=00:00 obj=system_u:system_r:udev_t:s0-s0:c0.c255 type=CWD msg=audit(01/01/2006 08:55:21.980:306) : cwd=/home/sgrubb/working/BUILD type=SYSCALL msg=audit(01/01/2006 08:55:21.980:306) : arch=x86_64 syscall=open success=no exit=-13(Permission denied) a0=3446610680 a1=0 a2=0 a3=0 items=1 pid=3497 auid=sgrubb uid=sgrubb gid=sgrubb euid=sgrubb suid=sgrubb fsuid=sgrubb egid=sgrubb sgid=sgrubb fsgid=sgrubb tty=tty2 comm=top exe=/usr/bin/top subj=user_u:system_r:unconfined_t:s0 type=AVC msg=audit(01/01/2006 08:55:21.980:306) : avc: denied { read } for pid=3497 comm=top name=stat dev=proc ino=27852814 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:udev_t:s0-s0:c0.c255 tclass=file pid 425 is udevd. I am wondering if this is just something that needs correcting in policy or if this is a case where polyinstantiation is needed for the proc file system. -Steve __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From dwalsh at redhat.com Mon Jan 2 14:22:23 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 02 Jan 2006 09:22:23 -0500 Subject: selinux policy upgrade avcs In-Reply-To: <20051231134552.69649.qmail@web51514.mail.yahoo.com> References: <20051231134552.69649.qmail@web51514.mail.yahoo.com> Message-ID: <43B9371F.8080808@redhat.com> Steve G wrote: > Hi, > > When yum updates my rawhide policy, I get these avcs: > > type=PATH msg=audit(12/29/2005 08:26:52.659:120) : item=0 name=/etc/mtab > inode=11403372 dev=03:07 mode=file,644 ouid=root ogid=root rdev=00:00 > obj=system_u:object_r:etc_runtime_t:s0 > type=CWD msg=audit(12/29/2005 08:26:52.659:120) : cwd=/ > type=SYSCALL msg=audit(12/29/2005 08:26:52.659:120) : arch=x86_64 syscall=open > success=no exit=-13(Permission denied) a0=3446313756 a1=0 a2=1b6 a3=0 items=1 > pid=2472 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root > sgid=root fsgid=root tty=tty1 comm=load_policy exe=/usr/sbin/load_policy > subj=root:system_r:load_policy_t:s0-s0:c0.c255 > type=AVC msg=audit(12/29/2005 08:26:52.659:120) : avc: denied { read } for > pid=2472 comm=load_policy name=mtab dev=hda7 ino=11403372 > scontext=root:system_r:load_policy_t:s0-s0:c0.c255 > tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file > > -Steve > This looks like a bug of a file descriptor being left open. Somthing in the kernel/init/initrd must be opening /etc/mtab and not setting closeonexec. Need to bugzilla the kernel I guess. > > > __________________________________________ > Yahoo! DSL ? Something to write home about. > Just $16.99/mo. or less. > dsl.yahoo.com > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From dwalsh at redhat.com Mon Jan 2 14:27:21 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 02 Jan 2006 09:27:21 -0500 Subject: Selinux warning? In-Reply-To: References: Message-ID: <43B93849.70904@redhat.com> Tom Diehl wrote: > Hi all, > > I have an EL4 box that every time I do su - vmail I get the following warnings > in the log: > > Dec 31 12:25:22 roger su(pam_unix)[2055]: session opened for user vmail by root(uid=0) > Dec 31 12:25:22 roger su[2055]: Warning! Could not relabel /dev/pts/3 with user_u:object_r:initrc_devpts_t, not relabeling.Operation not permitted > > This started after I changed the UID in /etc/passwd and the gid in /etc/group. > > (roger pts4) # ll -Z /dev/pts/3 > crw------- root tty root:object_r:initrc_devpts_t /dev/pts/3 > (roger pts4) # > > Is there something that needs to be done for selinux when I change a u/gid?? > > Regards, > > Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-lis > Not sure why your tty is labeled initrc_devpts_t. You could try to remove pam_selinux.so lines from your /etc/pam.d/su file and this should work fine. -- From linux_4ever at yahoo.com Mon Jan 2 18:39:13 2006 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 2 Jan 2006 10:39:13 -0800 (PST) Subject: selinux policy upgrade avcs In-Reply-To: <43B9371F.8080808@redhat.com> Message-ID: <20060102183913.39023.qmail@web51508.mail.yahoo.com> >This looks like a bug of a file descriptor being left open. Huh? This comes from running "yum update selinux-policy-targeted". Normal boots don't produce this avc. -Steve __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From nicolas.mailhot at laposte.net Mon Jan 2 19:19:20 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 02 Jan 2006 20:19:20 +0100 Subject: selinux kills SM In-Reply-To: <43A9CDD0.5040807@laposte.net> References: <43A9CDD0.5040807@laposte.net> Message-ID: <43B97CB8.7090102@laposte.net> Nicolas Mailhot wrote: > Hi, > > I don't really have the time to do a proper bug report, but today's > selinux update in rawhide killed squirelmail+dovecot. In fact I was unjust with SM, thunderbird is affected the same way -> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176789 Why so much mail hate ? Since I've tried to put my system in enforcing mode, I don't think there was a day when a component of my mail system was not blocked one way or another. Happy new year, -- Nicolas Mailhot From tdiehl at rogueind.com Tue Jan 3 00:24:39 2006 From: tdiehl at rogueind.com (Tom Diehl) Date: Mon, 2 Jan 2006 19:24:39 -0500 (EST) Subject: Selinux warning? In-Reply-To: <43B93849.70904@redhat.com> References: <43B93849.70904@redhat.com> Message-ID: On Mon, 2 Jan 2006, Daniel J Walsh wrote: > Tom Diehl wrote: > > Hi all, > > > > I have an EL4 box that every time I do su - vmail I get the following warnings > > in the log: > > > > Dec 31 12:25:22 roger su(pam_unix)[2055]: session opened for user vmail by root(uid=0) > > Dec 31 12:25:22 roger su[2055]: Warning! Could not relabel /dev/pts/3 with user_u:object_r:initrc_devpts_t, not relabeling.Operation not permitted > > > > (roger pts4) # ll -Z /dev/pts/3 > > crw------- root tty root:object_r:initrc_devpts_t /dev/pts/3 > > (roger pts4) # > > > Not sure why your tty is labeled initrc_devpts_t. You could try to > remove pam_selinux.so lines from your /etc/pam.d/su file and this should > work fine. This is a fully updated stock EL4 installation with no mods to pam or selinux. Is this some kind of bug or do the tty's need to be relabeled?? As far as I can tell, everything is working normally except for the warnings. In addition I looked a little harder and the warnings are showing up whenever I "su -" to any user. What if any downside is there to removing the pam_selinux.so lines as you suggested above? I would prefer to understand what is going on here. Unfortunately it is taking me way longer than I would like, to understand selinux. :-( Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From ben.youngdahl at gmail.com Tue Jan 3 02:30:24 2006 From: ben.youngdahl at gmail.com (Benjamin Youngdahl) Date: Mon, 2 Jan 2006 20:30:24 -0600 Subject: "data did not represent a module" error Message-ID: <291399270601021830h21bec4cvf2666243c97982fb@mail.gmail.com> Hello. I saw some previous discussions on this list regarding the message: "libsemanage.parse_module_headers: Data did not represent a module." when upgrading a policy RPM. Did I miss how to resolve this issue, and also what perhaps I'd manage to do to get things into this state? I'd appreciate any help you can give pointing me in the right direction. Best regards, Ben .... Here's my e.g. Downloading Packages: (1/1): selinux-policy-tar 100% |=========================| 443 kB 00:00 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating : selinux-policy-targeted ######################### [1/2] libsemanage.parse_module_headers: Data did not represent a module. Failed! /sbin/restorecon reset /usr/share/logwatch/scripts/logwatch.pl context system_u: object_r:bin_t->system_u:object_r:logwatch_exec_t /sbin/restorecon reset /var/cache/logwatch context system_u:object_r:var_t->system_u:object_r:logwatch_cache_t Cleanup : selinux-policy-targeted ######################### [2/2] -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at tycho.nsa.gov Tue Jan 3 15:00:37 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 03 Jan 2006 10:00:37 -0500 Subject: Curious Behavior doing routine redirection of ping output to (selinux: message 2 of 12) file... In-Reply-To: References: <43A8E5B0.8040902@funchords.com> <43A8EA49.4030504@mindspring.com> <43A8F39C.1060306@funchords.com> <43AB0CA4.8030809@redhat.com> Message-ID: <1136300437.27632.40.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-12-22 at 20:40 -0600, Robert Nichols wrote: > Daniel J Walsh wrote: > > ping runs under the ping_t domain and it is not allowed to write to the > > home dir. When you redirect in shell, shell has the application open > > the file which is not allowed. A hack to get around this problem is > > > > ping XYZ | cat > /home/dwalsh/myping > > It's actually the shell that opens the file for input or output > redirection, so apparently SELinux is denying a write to a file > that is already open for writing. Curious. SELinux rechecks access to open file descriptors when they are inherited across execve (if the security context of the process is changing, e.g. due to a domain transition, as in this case) and when they are transferred via local IPC. That is necessary to control the propagation of access rights in the system, required for mandatory access control. SELinux also rechecks access upon use (e.g. read(2) and write(2)) when possible to support limited revocation upon policy changes and object relabels, but revocation is difficult to support completely. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Jan 3 15:32:50 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 03 Jan 2006 10:32:50 -0500 Subject: reiser4 +selinux In-Reply-To: References: Message-ID: <1136302370.27632.62.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-12-29 at 10:24 -0600, Justin Conover wrote: > Does anyone know if reiser4 has the XATTRs added to handle selinux > now? It didn't last time I looked at reiser4. reiserfs (3) is also broken again for SELinux as of 2.6.14 and later. -- Stephen Smalley National Security Agency From selinux at gmail.com Tue Jan 3 15:33:51 2006 From: selinux at gmail.com (Tom London) Date: Tue, 3 Jan 2006 07:33:51 -0800 Subject: missing tmpfs_t in latest? Message-ID: <4c4ba1530601030733gf634955i48b2ba20ec5e8e98@mail.gmail.com> Running targeted, latest rawhide (e.g., selinux-policy-targeted-2.1.6-22). Reboot in enforcing mode fails: system goes into 'disk repair' mode. 'enforcing=0' works, but many messages. First, 'id -Z' in gnome terminal: [tbl at tlondon ~]$ id -Z system_u:system_r:xdm_t:SystemLow-SystemHigh [tbl at tlondon ~]$ 'audit2allow -d' shows... [root at tlondon ~]# audit2allow -d allow auditctl_t tmpfs_t:chr_file write; allow auditd_t tmpfs_t:chr_file getattr; allow auditd_t tmpfs_t:dir search; allow cpucontrol_t tmpfs_t:chr_file write; allow cpucontrol_t tmpfs_t:dir search; allow cpuspeed_t tmpfs_t:chr_file getattr; allow cpuspeed_t tmpfs_t:dir search; allow dhcpc_t tmpfs_t:chr_file { read write }; allow dhcpc_t tmpfs_t:dir search; allow fsadm_t tmpfs_t:blk_file ioctl; allow fsadm_t tmpfs_t:chr_file ioctl; allow hwclock_t tmpfs_t:chr_file getattr; allow hwclock_t tmpfs_t:dir search; allow ifconfig_t tmpfs_t:chr_file write; allow klogd_t tmpfs_t:dir search; allow klogd_t tmpfs_t:sock_file write; allow mount_t tmpfs_t:blk_file getattr; allow netutils_t tmpfs_t:chr_file write; allow pam_console_t tmpfs_t:blk_file setattr; allow pam_console_t tmpfs_t:chr_file setattr; allow pam_console_t tmpfs_t:dir search; allow pam_console_t tmpfs_t:lnk_file getattr; allow portmap_t tmpfs_t:chr_file getattr; allow portmap_t tmpfs_t:dir search; allow syslogd_t tmpfs_t:dir add_name; allow syslogd_t tmpfs_t:sock_file setattr; [root at tlondon ~]# Relabeling is borked: [root at tlondon ~]# restorecon -v -R /tmp file_contexts: invalid context system_u:object_r:tmp_t matchpathcon(/tmp) failed Invalid argument file_contexts: invalid context system_u:object_r:xdm_xserver_tmp_t matchpathcon(/tmp/.X0-lock) failed Invalid argument file_contexts: invalid context system_u:object_r:xfs_tmp_t matchpathcon(/tmp/.font-unix) failed Invalid argument file_contexts: invalid context system_u:object_r:xfs_tmp_t matchpathcon(/tmp/.font-unix/fs7100) failed Invalid argument [root at tlondon ~]# tom -- Tom London From dwalsh at redhat.com Tue Jan 3 17:46:00 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 03 Jan 2006 12:46:00 -0500 Subject: Selinux warning? In-Reply-To: References: <43B93849.70904@redhat.com> Message-ID: <43BAB858.206@redhat.com> Tom Diehl wrote: > On Mon, 2 Jan 2006, Daniel J Walsh wrote: > > >> Tom Diehl wrote: >> >>> Hi all, >>> >>> I have an EL4 box that every time I do su - vmail I get the following warnings >>> in the log: >>> >>> Dec 31 12:25:22 roger su(pam_unix)[2055]: session opened for user vmail by root(uid=0) >>> Dec 31 12:25:22 roger su[2055]: Warning! Could not relabel /dev/pts/3 with user_u:object_r:initrc_devpts_t, not relabeling.Operation not permitted >>> >>> (roger pts4) # ll -Z /dev/pts/3 >>> crw------- root tty root:object_r:initrc_devpts_t /dev/pts/3 >>> (roger pts4) # >>> >>> >> Not sure why your tty is labeled initrc_devpts_t. You could try to >> remove pam_selinux.so lines from your /etc/pam.d/su file and this should >> work fine. >> > > This is a fully updated stock EL4 installation with no mods to pam or selinux. > Is this some kind of bug or do the tty's need to be relabeled?? As far as I > can tell, everything is working normally except for the warnings. In addition > I looked a little harder and the warnings are showing up whenever I "su -" to > any user. > > What if any downside is there to removing the pam_selinux.so lines as you > suggested above? > > I would prefer to understand what is going on here. Unfortunately it is taking > me way longer than I would like, to understand selinux. :-( > > The pam_selinux.so lines were originally put in for strict/mls policy. They should have no effect for targeted policy, as you are seeing. The problem is that they are trying to set the the file context on a controlling terminal and policy is not allowing this. But this has no effect since you end up logging in as unconfined anyways. > Regards, > > Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com > From dwalsh at redhat.com Tue Jan 3 17:50:14 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 03 Jan 2006 12:50:14 -0500 Subject: missing tmpfs_t in latest? In-Reply-To: <4c4ba1530601030733gf634955i48b2ba20ec5e8e98@mail.gmail.com> References: <4c4ba1530601030733gf634955i48b2ba20ec5e8e98@mail.gmail.com> Message-ID: <43BAB956.2060103@redhat.com> Tom London wrote: > Running targeted, latest rawhide (e.g., selinux-policy-targeted-2.1.6-22). > > Reboot in enforcing mode fails: system goes into 'disk repair' mode. > > 'enforcing=0' works, but many messages. > > First, 'id -Z' in gnome terminal: > [tbl at tlondon ~]$ id -Z > system_u:system_r:xdm_t:SystemLow-SystemHigh > [tbl at tlondon ~]$ > > 'audit2allow -d' shows... > > [root at tlondon ~]# audit2allow -d > allow auditctl_t tmpfs_t:chr_file write; > allow auditd_t tmpfs_t:chr_file getattr; > allow auditd_t tmpfs_t:dir search; > allow cpucontrol_t tmpfs_t:chr_file write; > allow cpucontrol_t tmpfs_t:dir search; > allow cpuspeed_t tmpfs_t:chr_file getattr; > allow cpuspeed_t tmpfs_t:dir search; > allow dhcpc_t tmpfs_t:chr_file { read write }; > allow dhcpc_t tmpfs_t:dir search; > allow fsadm_t tmpfs_t:blk_file ioctl; > allow fsadm_t tmpfs_t:chr_file ioctl; > allow hwclock_t tmpfs_t:chr_file getattr; > allow hwclock_t tmpfs_t:dir search; > allow ifconfig_t tmpfs_t:chr_file write; > allow klogd_t tmpfs_t:dir search; > allow klogd_t tmpfs_t:sock_file write; > allow mount_t tmpfs_t:blk_file getattr; > allow netutils_t tmpfs_t:chr_file write; > allow pam_console_t tmpfs_t:blk_file setattr; > allow pam_console_t tmpfs_t:chr_file setattr; > allow pam_console_t tmpfs_t:dir search; > allow pam_console_t tmpfs_t:lnk_file getattr; > allow portmap_t tmpfs_t:chr_file getattr; > allow portmap_t tmpfs_t:dir search; > allow syslogd_t tmpfs_t:dir add_name; > allow syslogd_t tmpfs_t:sock_file setattr; > [root at tlondon ~]# > > Relabeling is borked: > [root at tlondon ~]# restorecon -v -R /tmp > file_contexts: invalid context system_u:object_r:tmp_t > matchpathcon(/tmp) failed Invalid argument > file_contexts: invalid context system_u:object_r:xdm_xserver_tmp_t > matchpathcon(/tmp/.X0-lock) failed Invalid argument > file_contexts: invalid context system_u:object_r:xfs_tmp_t > matchpathcon(/tmp/.font-unix) failed Invalid argument > file_contexts: invalid context system_u:object_r:xfs_tmp_t > matchpathcon(/tmp/.font-unix/fs7100) failed Invalid argument > [root at tlondon ~]# > > tom > -- > Tom London > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > This is caused by a bug in libsetrans. You can either disable libsetrans for the time being via /etc/selinux/targeted/setrans.conf or grab the updated libsetrans package from ftp://people.redhat.com/dwalsh/SELinux/Fedora Basically the untranslation of system_u:object_r:xfs_tmp_t -> system_u:object_r:xfs_tmp_t:s0 was broken by some optimizations that were added to libsetrans in last nights rawhide. Fix will be in tonights rawhide. From sds at tycho.nsa.gov Tue Jan 3 15:53:54 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 03 Jan 2006 10:53:54 -0500 Subject: "data did not represent a module" error In-Reply-To: <291399270601021830h21bec4cvf2666243c97982fb@mail.gmail.com> References: <291399270601021830h21bec4cvf2666243c97982fb@mail.gmail.com> Message-ID: <1136303634.27632.68.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2006-01-02 at 20:30 -0600, Benjamin Youngdahl wrote: > Hello. I saw some previous discussions on this list regarding the > message: > "libsemanage.parse_module_headers: Data did not represent a module." > when upgrading a policy RPM. > > Did I miss how to resolve this issue, and also what perhaps I'd manage > to do to get things into this state? I'd appreciate any help you can > give pointing me in the right direction. Looks like a packaging problem to me; something is running semodule -i on a module package that was built as a base policy module. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue Jan 3 18:23:19 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 03 Jan 2006 13:23:19 -0500 Subject: "data did not represent a module" error In-Reply-To: <1136303634.27632.68.camel@moss-spartans.epoch.ncsc.mil> References: <291399270601021830h21bec4cvf2666243c97982fb@mail.gmail.com> <1136303634.27632.68.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <43BAC117.5080008@redhat.com> Stephen Smalley wrote: > On Mon, 2006-01-02 at 20:30 -0600, Benjamin Youngdahl wrote: > >> Hello. I saw some previous discussions on this list regarding the >> message: >> "libsemanage.parse_module_headers: Data did not represent a module." >> when upgrading a policy RPM. >> >> Did I miss how to resolve this issue, and also what perhaps I'd manage >> to do to get things into this state? I'd appreciate any help you can >> give pointing me in the right direction. >> > > Looks like a packaging problem to me; something is running semodule -i > on a module package that was built as a base policy module. > > Ok the problem is that I have added enableaudit.pp and the post install is trying to load it. I need to change the postinstall to semodule -b /usr/share/selinux/%1/base.pp -s %1 \ for file in $(ls /usr/share/selinux/%1 | grep -v -e base.pp -e enableaudit.pp ) \ do \ semodule -i /usr/share/selinux/%1/$file -s %1;\ done; \ From gmaxwell at gmail.com Tue Jan 3 18:28:33 2006 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Tue, 3 Jan 2006 13:28:33 -0500 Subject: reiser4 +selinux In-Reply-To: References: Message-ID: On 12/29/05, Justin Conover wrote: > Does anyone know if reiser4 has the XATTRs added to handle selinux now? Reiser4 has the right structures to store things like XATTRs without stinking (unlike reiser3). Unfortunately, Resier4's developers were told that their preferred files-as-directories interface for extended attributes would be included in the mainline kernel around the time hell freezes over. This has resulted in the code being pulled, and extended attribute support in reiser4 has been left to bit rot. Attention on bringing it back will be given once reiser4 makes it into the mainline kernel... which is a sane ordering of priorities. Frankly, somethinglike selinux attrs on tmpfs would be a lot more important.. From sds at tycho.nsa.gov Tue Jan 3 19:04:14 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 03 Jan 2006 14:04:14 -0500 Subject: reiser4 +selinux In-Reply-To: References: Message-ID: <1136315054.27632.155.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-01-03 at 13:28 -0500, Gregory Maxwell wrote: > On 12/29/05, Justin Conover wrote: > > Does anyone know if reiser4 has the XATTRs added to handle selinux now? > > Reiser4 has the right structures to store things like XATTRs without > stinking (unlike reiser3). Unfortunately, Resier4's developers were > told that their preferred files-as-directories interface for extended > attributes would be included in the mainline kernel around the time > hell freezes over. This has resulted in the code being pulled, and > extended attribute support in reiser4 has been left to bit rot. > > Attention on bringing it back will be given once reiser4 makes it into > the mainline kernel... which is a sane ordering of priorities. > > Frankly, somethinglike selinux attrs on tmpfs would be a lot more important.. SELinux attributes on tmpfs have been around for some time. They were needed for udev with a tmpfs /dev. -- Stephen Smalley National Security Agency From gmaxwell at gmail.com Tue Jan 3 19:11:45 2006 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Tue, 3 Jan 2006 14:11:45 -0500 Subject: Curious Behavior doing routine redirection of ping output to (selinux: message 2 of 12) file... In-Reply-To: <1136300437.27632.40.camel@moss-spartans.epoch.ncsc.mil> References: <43A8E5B0.8040902@funchords.com> <43A8EA49.4030504@mindspring.com> <43A8F39C.1060306@funchords.com> <43AB0CA4.8030809@redhat.com> <1136300437.27632.40.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On 1/3/06, Stephen Smalley wrote: > > > ping XYZ | cat > /home/dwalsh/myping > > > > It's actually the shell that opens the file for input or output > > redirection, so apparently SELinux is denying a write to a file > > that is already open for writing. Curious. > > SELinux rechecks access to open file descriptors when they are inherited > across execve (if the security context of the process is changing, e.g. > due to a domain transition, as in this case) and when they are > transferred via local IPC. That is necessary to control the propagation > of access rights in the system, required for mandatory access control. > SELinux also rechecks access upon use (e.g. read(2) and write(2)) when > possible to support limited revocation upon policy changes and object > relabels, but revocation is difficult to support completely. Would it be inappropriate add a compile time flag to bash to cause such redirection to always bounce through the shell? Obviously there would be a performance hit... but the mysterious failure is probably worse... From jallits at gmail.com Tue Jan 3 20:42:37 2006 From: jallits at gmail.com (Dan Jallits) Date: Tue, 3 Jan 2006 14:42:37 -0600 Subject: Mozilla Firefox and Fedora selinux Core 4 Message-ID: Okay I have searched the filesystem and still can find the path, but where is the Mozilla/plugins directory. Come on guys help the Noobie out here! -- Best regards, Daniel C. Jallits 100 E. Oneida Avenue Elmhurst, Illinois 60126-4465 United States of America T: 630.279.2798 | M: 630.670.3775 Email - jallits at gmail.com Weblog - http://jallits.wordpress.com Del.icio.us - http://del.icio.us/rss/jallits Technorati - http://www.technorati.com/profile/jallits From dotancohen at gmail.com Thu Jan 5 00:40:24 2006 From: dotancohen at gmail.com (Dotan Cohen) Date: Thu, 5 Jan 2006 02:40:24 +0200 Subject: Mozilla Firefox and Fedora selinux Core 4 In-Reply-To: References: Message-ID: <880dece00601041640r8c286f9jd94b5ce9078687c4@mail.gmail.com> On 1/3/06, Dan Jallits wrote: > Okay I have searched the filesystem and still can find the path, but > where is the Mozilla/plugins directory. > > Come on guys help the Noobie out here! It should be here: /home//.mozilla/plugins Dotan Cohen http://technology-sleuth.com/technical_answer/what_is_a_firewall.html ^% From tim at birdsnest.maths.tcd.ie Thu Jan 5 14:30:59 2006 From: tim at birdsnest.maths.tcd.ie (Timothy Murphy) Date: Thu, 05 Jan 2006 14:30:59 +0000 Subject: FC4 documentation for apache + selinux ? Message-ID: Is there any documentation about the interaction of selinux and apache under Fedora-4? I looked at "Understanding and Customizing the Apache HTTP SELinux Policy" at , but the changes between FC3 and FC4 seemed to make much of this irrelevant. Is there a corresponding document for FC4? -- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From paul at city-fan.org Thu Jan 5 14:36:39 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 05 Jan 2006 14:36:39 +0000 Subject: FC4 documentation for apache + selinux ? In-Reply-To: References: Message-ID: <43BD2EF7.2030806@city-fan.org> Timothy Murphy wrote: > Is there any documentation about the interaction > of selinux and apache under Fedora-4? > > I looked at "Understanding and Customizing the Apache HTTP SELinux Policy" > at , > but the changes between FC3 and FC4 seemed to make much of this irrelevant. > > Is there a corresponding document for FC4? Most of the principles remain the same in FC4. I think the biggest single thing that you need to remember is that FC4 uses the "targeted" policy by default, whilst the examples in the document are for the "strict" policy. Do the appropriate substitutions in examples and most things will work. It's also worth reading "man httpd_selinux" Paul. From tim at birdsnest.maths.tcd.ie Thu Jan 5 15:08:52 2006 From: tim at birdsnest.maths.tcd.ie (Timothy Murphy) Date: Thu, 05 Jan 2006 15:08:52 +0000 Subject: FC4 documentation for apache + selinux ? References: <43BD2EF7.2030806@city-fan.org> Message-ID: Paul Howarth wrote: >> I looked at "Understanding and Customizing the Apache HTTP SELinux >> Policy" at , >> but the changes between FC3 and FC4 seemed to make much of this >> irrelevant. >> >> Is there a corresponding document for FC4? > > Most of the principles remain the same in FC4. I think the biggest > single thing that you need to remember is that FC4 uses the "targeted" > policy by default, whilst the examples in the document are for the > "strict" policy. Do the appropriate substitutions in examples and most > things will work. Some suggestions in this document which did not work for me under FC4. (I did not run selinux under FC3.) 1) "Your first step is to install the httpd package, and probably the httpd-suexec and httpd-manual packages." There does not seem to be an httpd-suexec rpm for FC4. 2) By default, SELinux enforcement for Apache HTTP is enabled. To verify this, run system-config-securitylevel, and view the SELinux tab. Click on the Transition tree, and ensure that Disable SELinux protection for httpd daemon is not checked. What is the "Transition tree"? Does this mean the list of "Trusted services"? (If so, why not say that??) In my case https and http have check-marks against them. But what exactly does "Trusted services" mean? Does it mean that selinux trusts these services, and so does not concern itself with them? Or does it mean the opposite, that selinux _is_ looking after them? And what on earth does "Enforcing current Disabled" mean when I click the SELinux tag? The effect of clicking OK on leaving system-config-securitylevel on my desktop linked to the internet is to cut off access to the web from my laptop, even though the relevant device (/dev/eth2) is clicked under Trusted devices. 3) " As a further check, use the command ps axZ | grep httpd. You should see it running in the root_u:system_r:httpd_t security context. The important part of that is the third component, the httpd_t type." When I run this command, I do not get this response, or anything like it: ------------------------------- [tim at alfred ~]$ ps axZ | grep httpd kernel 13047 ? Ss 0:00 /usr/sbin/httpd kernel 24171 ? S 0:00 /usr/sbin/httpd kernel 24172 ? S 0:00 /usr/sbin/httpd kernel 24173 ? S 0:00 /usr/sbin/httpd kernel 24174 ? S 0:00 /usr/sbin/httpd kernel 24175 ? S 0:00 /usr/sbin/httpd kernel 13204 pts/3 S+ 0:00 grep httpd ------------------------------- In effect, hardly anything on the "Getting Started" page seems to work for me ... -- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From paul at city-fan.org Thu Jan 5 15:17:10 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 05 Jan 2006 15:17:10 +0000 Subject: FC4 documentation for apache + selinux ? In-Reply-To: References: <43BD2EF7.2030806@city-fan.org> Message-ID: <43BD3876.50904@city-fan.org> Timothy Murphy wrote: > Paul Howarth wrote: > > >>>I looked at "Understanding and Customizing the Apache HTTP SELinux >>>Policy" at , >>>but the changes between FC3 and FC4 seemed to make much of this >>>irrelevant. >>> >>>Is there a corresponding document for FC4? >> >>Most of the principles remain the same in FC4. I think the biggest >>single thing that you need to remember is that FC4 uses the "targeted" >>policy by default, whilst the examples in the document are for the >>"strict" policy. Do the appropriate substitutions in examples and most >>things will work. > > > Some suggestions in this document which did not work for me under FC4. > (I did not run selinux under FC3.) > > 1) "Your first step is to install the httpd package, and probably the > httpd-suexec and httpd-manual packages." > > There does not seem to be an httpd-suexec rpm for FC4. The suexec program is contained within the main httpd package in FC4, so that's indeed a difference. > 2) By default, SELinux enforcement for Apache HTTP is enabled. To verify > this, run system-config-securitylevel, and view the SELinux tab. Click on > the Transition tree, and ensure that Disable SELinux protection for httpd > daemon is not checked. > > What is the "Transition tree"? > Does this mean the list of "Trusted services"? > (If so, why not say that??) > > In my case https and http have check-marks against them. > But what exactly does "Trusted services" mean? > Does it mean that selinux trusts these services, > and so does not concern itself with them? > Or does it mean the opposite, > that selinux _is_ looking after them? > > And what on earth does "Enforcing current Disabled" mean > when I click the SELinux tag? I can't answer these personally as I use the command-line tools rather than the GUI. Hopefully Dan will follow up on that. > 3) " As a further check, use the command ps axZ | grep httpd. > You should see it running in the root_u:system_r:httpd_t security context. > The important part of that is the third component, the httpd_t type." > > When I run this command, I do not get this response, > or anything like it: > ------------------------------- > [tim at alfred ~]$ ps axZ | grep httpd > kernel 13047 ? Ss 0:00 /usr/sbin/httpd > kernel 24171 ? S 0:00 /usr/sbin/httpd > kernel 24172 ? S 0:00 /usr/sbin/httpd > kernel 24173 ? S 0:00 /usr/sbin/httpd > kernel 24174 ? S 0:00 /usr/sbin/httpd > kernel 24175 ? S 0:00 /usr/sbin/httpd > kernel 13204 pts/3 S+ 0:00 grep httpd > ------------------------------- What's the output of: # getsebool -a | grep httpd Paul. From sds at tycho.nsa.gov Thu Jan 5 15:31:36 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 05 Jan 2006 10:31:36 -0500 Subject: FC4 documentation for apache + selinux ? In-Reply-To: References: <43BD2EF7.2030806@city-fan.org> Message-ID: <1136475097.27632.414.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-01-05 at 15:08 +0000, Timothy Murphy wrote: > 2) By default, SELinux enforcement for Apache HTTP is enabled. To verify > this, run system-config-securitylevel, and view the SELinux tab. Click on > the Transition tree, and ensure that Disable SELinux protection for httpd > daemon is not checked. > > What is the "Transition tree"? > Does this mean the list of "Trusted services"? > (If so, why not say that??) Caveat: I rarely look at or use the GUI, but looking briefly at it, I would say: No, the "trusted services" list is for the firewall, not SELinux-related. For SELinux settings, select the SELinux tab, go down to the "Modify SELinux Policy" box, and expand HTTPD Service, then look for "Disable SELinux protection for httpd daemon" and make sure it isn't checked. I assume that it used to be called Transition tree at the time that Colin wrote his document. > And what on earth does "Enforcing current Disabled" mean > when I click the SELinux tag? Enforcing checkbox lets you toggle between Enforcing and Permissive modes. The Current: info tells you the current status of SELinux, which apparently is disabled on your system. > The effect of clicking OK on leaving system-config-securitylevel > on my desktop linked to the internet > is to cut off access to the web from my laptop, > even though the relevant device (/dev/eth2) > is clicked under Trusted devices. You shouldn't have to mark the device as trusted in order to perform outbound connections. 'Trusted' in the firewall tab indicates trust for inbound access, IIRC (again, not using this GUI myself). I have no trusted services or devices marked. > > 3) " As a further check, use the command ps axZ | grep httpd. > You should see it running in the root_u:system_r:httpd_t security context. > The important part of that is the third component, the httpd_t type." > > When I run this command, I do not get this response, > or anything like it: > ------------------------------- > [tim at alfred ~]$ ps axZ | grep httpd > kernel 13047 ? Ss 0:00 /usr/sbin/httpd > kernel 24171 ? S 0:00 /usr/sbin/httpd > kernel 24172 ? S 0:00 /usr/sbin/httpd > kernel 24173 ? S 0:00 /usr/sbin/httpd > kernel 24174 ? S 0:00 /usr/sbin/httpd > kernel 24175 ? S 0:00 /usr/sbin/httpd > kernel 13204 pts/3 S+ 0:00 grep httpd > ------------------------------- This output suggests that no policy was loaded on your system. -- Stephen Smalley National Security Agency From lamont at gurulabs.com Thu Jan 5 19:14:56 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 5 Jan 2006 12:14:56 -0700 Subject: FC4 documentation for apache + selinux ? In-Reply-To: <1136475097.27632.414.camel@moss-spartans.epoch.ncsc.mil> References: <1136475097.27632.414.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200601051215.00662.lamont@gurulabs.com> On Thursday 05 January 2006 08:31am, Stephen Smalley wrote: > On Thu, 2006-01-05 at 15:08 +0000, Timothy Murphy wrote: > > 2) By default, SELinux enforcement for Apache HTTP is enabled. To verify > > this, run system-config-securitylevel, and view the SELinux tab. Click on > > the Transition tree, and ensure that Disable SELinux protection for httpd > > daemon is not checked. > > > > What is the "Transition tree"? > > Does this mean the list of "Trusted services"? > > (If so, why not say that??) > > Caveat: I rarely look at or use the GUI, but looking briefly at it, I > would say: > > No, the "trusted services" list is for the firewall, not > SELinux-related. For SELinux settings, select the SELinux tab, go down > to the "Modify SELinux Policy" box, and expand HTTPD Service, then look > for "Disable SELinux protection for httpd daemon" and make sure it isn't > checked. I assume that it used to be called Transition tree at the time > that Colin wrote his document. > > > And what on earth does "Enforcing current Disabled" mean > > when I click the SELinux tag? > > Enforcing checkbox lets you toggle between Enforcing and Permissive > modes. The Current: info tells you the current status of SELinux, which > apparently is disabled on your system. > > > The effect of clicking OK on leaving system-config-securitylevel > > on my desktop linked to the internet > > is to cut off access to the web from my laptop, > > even though the relevant device (/dev/eth2) > > is clicked under Trusted devices. > > You shouldn't have to mark the device as trusted in order to perform > outbound connections. 'Trusted' in the firewall tab indicates trust for > inbound access, IIRC (again, not using this GUI myself). I have no > trusted services or devices marked. Stephen is correct; the "Trusted Devices" list causes a rule to be added to the firewall configuration created by system-config-securitylevel for each NIC (i.e. "device") which is checked. Those rules allow all incoming traffic on the specified interface(s) without going through any of the other firewall checks. You should *not* check those boxes, ever. Of course, people do, but then there is no firewall. The list of services in the firewall tab will, when checked, create a rule that allows *inbound* connections for that service. There are only 4 services on that list. You can add a space separated list of additional ports to allow in the text input box provided. The entries would look like "tcp:3128 udp:53 tcp:53 tcp:953" in that box. This is much better than checking the "Trusted Devices" boxes. [snip] -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sindybear at 163.com Fri Jan 6 16:20:26 2006 From: sindybear at 163.com (William Xiong) Date: Fri, 06 Jan 2006 16:20:26 +0000 Subject: libselinux bug or not Message-ID: <43BE98CA.8080306@163.com> when I use pam system to program, I invoke pam_chauthtok function to change passwd, If I put this piece of code in the main thread of a process, then everything is ok, but if i put the code into a child thread, then it will return failed status. when i trace the code, I found the pam system use selinux, the pam system will invoke setfscreatecon() function. the implemention of setfscreatecon() use below code to change fscreate stat: fd = open("/proc/self/attr/fscreate", O_RDWR); but, if the thread invode setfscreatecon() is a child thread in a process, then, the /proc/self will point the main thread of the process, not the child thread's own proc subdir. then the following code will fail. can some find the same problem? From linux_4ever at yahoo.com Fri Jan 6 11:34:20 2006 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 6 Jan 2006 03:34:20 -0800 (PST) Subject: libselinux bug or not In-Reply-To: <43BE98CA.8080306@163.com> Message-ID: <20060106113420.75442.qmail@web51504.mail.yahoo.com> >but, if the thread invode setfscreatecon() is a child thread in a >process, then, the /proc/self will point the main thread of the process This may not be the exact answer you want...but pam is not thread safe at all. Not just for this reason, but because it uses functions that are known to be unsafe in threaded apps. -Steve __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From sds at tycho.nsa.gov Fri Jan 6 12:57:39 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 06 Jan 2006 07:57:39 -0500 Subject: libselinux bug or not In-Reply-To: <43BE98CA.8080306@163.com> References: <43BE98CA.8080306@163.com> Message-ID: <1136552259.16811.3.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-01-06 at 16:20 +0000, William Xiong wrote: > when I use pam system to program, I invoke > pam_chauthtok function to change passwd, If I put this piece of code in > the main thread of a process, then everything is ok, but if i put the > code into a child thread, then it will return failed status. > > when i trace the code, I found the pam system use selinux, the pam > system will invoke setfscreatecon() function. the implemention of > setfscreatecon() use below code to change fscreate stat: > > fd = open("/proc/self/attr/fscreate", O_RDWR); > > but, if the thread invode setfscreatecon() is a child thread in a > process, then, the /proc/self will point the main thread of the process, > not the child thread's own proc subdir. then the following code will fail. > > can some find the same problem? Hi, Yes, the libselinux functions presently don't allow for a child thread to modify its process security attributes. The change in structure of /proc and meaning of /proc/self occurred very late in Linux 2.5 (actually in 2.6.0-test, IIRC). We could possibly alter libselinux to instead access /proc/self/task//attr/... for the fscreate attribute (security label to apply to newly created files by the thread), although it wouldn't make much sense to do so for the exec attribute, and it isn't permitted for the current attribute to differ among threads since they share memory. However, before doing so, we would need a concrete justification, and it sounds like pam isn't thread-safe anyway according to Steve G's posting. -- Stephen Smalley National Security Agency From tim at birdsnest.maths.tcd.ie Fri Jan 6 14:36:38 2006 From: tim at birdsnest.maths.tcd.ie (Timothy Murphy) Date: Fri, 06 Jan 2006 14:36:38 +0000 Subject: FC4 documentation for apache + selinux ? References: <43BD2EF7.2030806@city-fan.org> <43BD3876.50904@city-fan.org> Message-ID: Paul Howarth wrote: > What's the output of: > > # getsebool -a | grep httpd Thanks to you all for your attempts to help me. The response to the above query is ------------------------------- [tim at alfred ~]$ getsebool -a | grep httpd getsebool: SELinux is disabled ------------------------------- I'm not clear why this is, as when I run system-config-securitylevel and click on the SELinux tab there are 3 checkboxes, the first of which is entitled "Enabled (Modification Requires Reboot)". This is ticked (and always has been), which I took to mean that SELinux was enabled. The second checkbox, which is also ticked, is entitled "Enforcing Current Disabled" which I find unintelligible. The third checkbox, which is not ticked, is entitled "Relabel on next reboot", which I also find unintelligible. Returning for a moment to the Firewall Options tab, I'm actually running shorewall, which I am quite happy with, and would prefer not to change. (I'm running the standard "two-interfaces" rules.) If I wanted to run selinux, do I need to enable the firewall given in the system-config-securitylevel tab? Or are the services in the two tabs independent? If so, might I suggest it would be better to have two different system-config-* programs? My position is that I would like to run selinux if it were reasonably clear how to do this; but at the moment clicking OK on leaving system-config-securitylevel has the effect of cutting off my laptop access to the internet. I don't really feel in any great security danger, so selinux is not top of my list of priorities; if it were possible to run it, after spending say 1 or 2 hours reading the documentation, and if it did not then affect my current usage, I would do it. Of course my situation is not important on a global scale; but I imagine there must be many Fedora users whose attitude to selinux is much the same as mine. I would not have thought it would take very long, after making what appear to be major changes to SELinux, to modify the documentation to take account of the changes. -- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From linux_4ever at yahoo.com Fri Jan 6 14:41:15 2006 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 6 Jan 2006 06:41:15 -0800 (PST) Subject: hald avcs Message-ID: <20060106144115.79271.qmail@web51510.mail.yahoo.com> Hi, I just updated to current rawhide and I am now getting a lot of avcs from hald. You can recreate this by running: aureport -a --failed -Steve AVC Report ============================================== # date time comm subj syscall action obj event ============================================== 1. 01/06/2006 09:23:25 AM hald system_u:system_r:hald_t:s0 execve execute system_u:object_r:usr_t:s0 denied 54 2. 01/06/2006 09:23:27 AM hald system_u:system_r:hald_t:s0 stat getattr system_u:object_r:boot_t:s0 denied 55 3. 01/06/2006 09:23:27 AM hald system_u:system_r:hald_t:s0 stat search system_u:object_r:var_log_t:s0 denied 56 4. 01/06/2006 09:23:27 AM hald system_u:system_r:hald_t:s0 stat search system_u:object_r:sysctl_fs_t:s0 denied 57 5. 01/06/2006 09:23:27 AM hald system_u:system_r:hald_t:s0 stat getattr system_u:object_r:boot_t:s0 denied 58 6. 01/06/2006 09:23:27 AM hald system_u:system_r:hald_t:s0 stat search system_u:object_r:var_log_t:s0 denied 59 7. 01/06/2006 09:23:27 AM hald system_u:system_r:hald_t:s0 stat search system_u:object_r:sysctl_fs_t:s0 denied 60 8. 01/06/2006 09:23:27 AM hald system_u:system_r:hald_t:s0 stat getattr system_u:object_r:boot_t:s0 denied 61 9. 01/06/2006 09:23:27 AM hald system_u:system_r:hald_t:s0 stat search system_u:object_r:var_log_t:s0 denied 62 10. 01/06/2006 09:23:27 AM hald system_u:system_r:hald_t:s0 stat search system_u:object_r:sysctl_fs_t:s0 denied 63 11. 01/06/2006 09:23:27 AM hald system_u:system_r:hald_t:s0 stat getattr system_u:object_r:boot_t:s0 denied 64 12. 01/06/2006 09:23:27 AM hald system_u:system_r:hald_t:s0 stat search system_u:object_r:var_log_t:s0 denied 65 13. 01/06/2006 09:23:27 AM hald system_u:system_r:hald_t:s0 stat search system_u:object_r:sysctl_fs_t:s0 denied 66 14. 01/06/2006 09:23:28 AM hald system_u:system_r:hald_t:s0 stat getattr system_u:object_r:boot_t:s0 denied 67 15. 01/06/2006 09:23:28 AM hald system_u:system_r:hald_t:s0 stat search system_u:object_r:var_log_t:s0 denied 68 16. 01/06/2006 09:23:28 AM hald system_u:system_r:hald_t:s0 stat search system_u:object_r:sysctl_fs_t:s0 denied 69 17. 01/06/2006 09:23:28 AM hald system_u:system_r:hald_t:s0 stat getattr system_u:object_r:boot_t:s0 denied 70 18. 01/06/2006 09:23:28 AM hald system_u:system_r:hald_t:s0 stat search system_u:object_r:var_log_t:s0 denied 71 19. 01/06/2006 09:23:28 AM hald system_u:system_r:hald_t:s0 stat search system_u:object_r:sysctl_fs_t:s0 denied 72 20. 01/06/2006 09:23:28 AM hald system_u:system_r:hald_t:s0 stat getattr system_u:object_r:boot_t:s0 denied 73 21. 01/06/2006 09:23:28 AM hald system_u:system_r:hald_t:s0 stat search system_u:object_r:var_log_t:s0 denied 74 22. 01/06/2006 09:23:28 AM hald system_u:system_r:hald_t:s0 stat search system_u:object_r:sysctl_fs_t:s0 denied 75 __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From dwalsh at redhat.com Fri Jan 6 15:00:20 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 06 Jan 2006 10:00:20 -0500 Subject: FC4 documentation for apache + selinux ? In-Reply-To: <43BD3876.50904@city-fan.org> References: <43BD2EF7.2030806@city-fan.org> <43BD3876.50904@city-fan.org> Message-ID: <43BE8604.3040407@redhat.com> Paul Howarth wrote: > Timothy Murphy wrote: >> Paul Howarth wrote: >> >> >>>> I looked at "Understanding and Customizing the Apache HTTP SELinux >>>> Policy" at >>>> , >>>> but the changes between FC3 and FC4 seemed to make much of this >>>> irrelevant. >>>> >>>> Is there a corresponding document for FC4? >>> >>> Most of the principles remain the same in FC4. I think the biggest >>> single thing that you need to remember is that FC4 uses the "targeted" >>> policy by default, whilst the examples in the document are for the >>> "strict" policy. Do the appropriate substitutions in examples and most >>> things will work. >> >> >> Some suggestions in this document which did not work for me under FC4. >> (I did not run selinux under FC3.) >> >> 1) "Your first step is to install the httpd package, and probably the >> httpd-suexec and httpd-manual packages." >> >> There does not seem to be an httpd-suexec rpm for FC4. > > The suexec program is contained within the main httpd package in FC4, > so that's indeed a difference. > >> 2) By default, SELinux enforcement for Apache HTTP is enabled. To >> verify >> this, run system-config-securitylevel, and view the SELinux tab. >> Click on >> the Transition tree, and ensure that Disable SELinux protection for >> httpd >> daemon is not checked. >> >> What is the "Transition tree"? >> Does this mean the list of "Trusted services"? >> (If so, why not say that??) >> >> In my case https and http have check-marks against them. >> But what exactly does "Trusted services" mean? >> Does it mean that selinux trusts these services, >> and so does not concern itself with them? >> Or does it mean the opposite, >> that selinux _is_ looking after them? >> >> And what on earth does "Enforcing current Disabled" mean >> when I click the SELinux tag? > > I can't answer these personally as I use the command-line tools rather > than the GUI. Hopefully Dan will follow up on that. This indicates selinux is disabled on this machine. If you want to turn on SELinux, you need to install selinux-targeted-policy Make sure /etc/selinux/config has SELINUX=enforcing (Or Permissive) and SELINUXTYPE=targeted Also make sure you don't have selinux=0 in /etc/grub.conf touch /.autorelabel and reboot. > >> 3) " As a further check, use the command ps axZ | grep httpd. >> You should see it running in the root_u:system_r:httpd_t security >> context. >> The important part of that is the third component, the httpd_t type." >> >> When I run this command, I do not get this response, >> or anything like it: >> ------------------------------- >> [tim at alfred ~]$ ps axZ | grep httpd >> kernel 13047 ? Ss 0:00 >> /usr/sbin/httpd >> kernel 24171 ? S 0:00 >> /usr/sbin/httpd >> kernel 24172 ? S 0:00 >> /usr/sbin/httpd >> kernel 24173 ? S 0:00 >> /usr/sbin/httpd >> kernel 24174 ? S 0:00 >> /usr/sbin/httpd >> kernel 24175 ? S 0:00 >> /usr/sbin/httpd >> kernel 13204 pts/3 S+ 0:00 grep httpd >> ------------------------------- > > What's the output of: > > # getsebool -a | grep httpd > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From karyl.lists at mailforest.com Fri Jan 6 19:16:20 2006 From: karyl.lists at mailforest.com (Karyl F. Stein) Date: Fri, 06 Jan 2006 14:16:20 -0500 Subject: Postfix virtual and Dovecot Message-ID: <43BEC204.6040309@mailforest.com> Any ideas on how I can get the Postfix virtual transport to deliver to a maildir and have Dovecot pick it up? I can get one or the other to work, but not both. The maildirs are in /srv/mirror/mail. If I make that directory have the postfix_spool_t context, Postfix writes there fine, but Dovecot can't access it. If I make the directory have mail_spool_t, then Dovecot can access it, but Postfix can't. As far as I can tell, there doesn't seem to be a common context. I'm running FC4 with the targeted policy. Thanks, Karyl From paul at city-fan.org Fri Jan 6 20:10:51 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 06 Jan 2006 20:10:51 +0000 Subject: Postfix virtual and Dovecot In-Reply-To: <43BEC204.6040309@mailforest.com> References: <43BEC204.6040309@mailforest.com> Message-ID: <1136578251.28374.24.camel@laurel.intra.city-fan.org> On Fri, 2006-01-06 at 14:16 -0500, Karyl F. Stein wrote: > Any ideas on how I can get the Postfix virtual transport to deliver to a > maildir and have Dovecot pick it up? I can get one or the other to > work, but not both. The maildirs are in /srv/mirror/mail. If I make > that directory have the postfix_spool_t context, Postfix writes there > fine, but Dovecot can't access it. If I make the directory have > mail_spool_t, then Dovecot can access it, but Postfix can't. As far as > I can tell, there doesn't seem to be a common context. > > I'm running FC4 with the targeted policy. Perhaps postfix works differently to sendmail but I use procmail to deliver mail received by sendmail to maildirs under /var/spool/mail, which is mail_spool_t and hence works fine with dovecot. (having just looked at the policy sources, the one for postfix is vastly more complicated than the sendmail one so it does indeed appear to be different...) Paul. From nicolas.mailhot at laposte.net Fri Jan 6 21:15:05 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 06 Jan 2006 22:15:05 +0100 Subject: Postfix virtual and Dovecot In-Reply-To: <43BEC204.6040309@mailforest.com> References: <43BEC204.6040309@mailforest.com> Message-ID: <1136582105.31349.10.camel@rousalka.dyndns.org> Le vendredi 06 janvier 2006 ? 14:16 -0500, Karyl F. Stein a ?crit : > Any ideas on how I can get the Postfix virtual transport to deliver to a > maildir and have Dovecot pick it up? I can get one or the other to > work, but not both. The maildirs are in /srv/mirror/mail. If I make > that directory have the postfix_spool_t context, Postfix writes there > fine, but Dovecot can't access it. If I make the directory have > mail_spool_t, then Dovecot can access it, but Postfix can't. As far as > I can tell, there doesn't seem to be a common context. > > I'm running FC4 with the targeted policy. I use this : I. In /etc/postfix/main.cf mailbox_command = /usr/bin/procmail II. In /etc/procmailrc MAILDIR=$HOME/.maildir DEFAULT=./ LOGFILE=$MAILDIR/logfile and if you want SPAM=.Spam.Auto/ :0fw: .spamc.lock * < 256000 | spamc :0 * ^X-Spam-Status: Yes $SPAM III. In /etc/dovecot.conf default_mail_env = maildir:%h/.maildir Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tim at birdsnest.maths.tcd.ie Sat Jan 7 01:03:23 2006 From: tim at birdsnest.maths.tcd.ie (Timothy Murphy) Date: Sat, 07 Jan 2006 01:03:23 +0000 Subject: FC4 documentation for apache + selinux ? References: <43BD2EF7.2030806@city-fan.org> <43BD3876.50904@city-fan.org> <43BE8604.3040407@redhat.com> Message-ID: Daniel J Walsh wrote: >>> And what on earth does "Enforcing current Disabled" mean >>> when I click the SELinux tag? > This indicates selinux is disabled on this machine. Sorry to be awkward, but if "Enforcing current Disabled" means "SELinux disabled", would it not be simpler to say this? > If you want to turn > on SELinux, you need to install selinux-targeted-policy > Make sure /etc/selinux/config has > SELINUX=enforcing (Or Permissive) > and > SELINUXTYPE=targeted > Also make sure you don't have selinux=0 in /etc/grub.conf > > touch /.autorelabel and reboot. Thanks for the advice, which I'll try to follow. It strikes me as a funny way to implement a program, though. Actually, my /etc/selinux/config does have SELINUX=enforcing SELINUXTYPE=targeted and there is no mention of selinux in grub.conf . (But I'm glad to know I could put it there.) But I do not find any selinux-targeted-policy rpm. How exactly does one install this? -- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From karyl.lists at mailforest.com Sat Jan 7 04:23:24 2006 From: karyl.lists at mailforest.com (Karyl F. Stein) Date: Fri, 06 Jan 2006 23:23:24 -0500 Subject: Postfix virtual and Dovecot In-Reply-To: <1136582105.31349.10.camel@rousalka.dyndns.org> References: <43BEC204.6040309@mailforest.com> <1136582105.31349.10.camel@rousalka.dyndns.org> Message-ID: <43BF423C.1010107@mailforest.com> Nicolas Mailhot wrote: >I use this : > >I. In /etc/postfix/main.cf > >mailbox_command = /usr/bin/procmail > >II. In /etc/procmailrc > >MAILDIR=$HOME/.maildir >DEFAULT=./ >LOGFILE=$MAILDIR/logfile > >and if you want > >SPAM=.Spam.Auto/ > >:0fw: .spamc.lock >* < 256000 >| spamc > >:0 >* ^X-Spam-Status: Yes >$SPAM > >III. In /etc/dovecot.conf >default_mail_env = maildir:%h/.maildir > >Regards, > > > Thanks, Nicolas. My email users do not have UNIX accounts, which makes things a little more difficult. However, your suggestion of using an alternate transport brought me to maildrop. It looks like maildrop might work nicely for what I need and seems to be documented in Postfix. However, I'd rather not install another layer of complexity if possible. Can you do something like create a "local" policy that won't be overwritten when a new targeted policy RPM is released? That way I could configure Postfix to have write access to mail_spool_t. From paul at city-fan.org Sat Jan 7 10:45:28 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 07 Jan 2006 10:45:28 +0000 Subject: FC4 documentation for apache + selinux ? In-Reply-To: References: <43BD2EF7.2030806@city-fan.org> <43BD3876.50904@city-fan.org> <43BE8604.3040407@redhat.com> Message-ID: <1136630728.28374.41.camel@laurel.intra.city-fan.org> On Sat, 2006-01-07 at 01:03 +0000, Timothy Murphy wrote: > > touch /.autorelabel and reboot. > > Thanks for the advice, which I'll try to follow. > It strikes me as a funny way to implement a program, though. This causes all the files on your system to be labelled with the default security context at the next reboot. It could take quite a while to do. > Actually, my /etc/selinux/config does have > > SELINUX=enforcing > SELINUXTYPE=targeted > > and there is no mention of selinux in grub.conf . > (But I'm glad to know I could put it there.) These are OK but didn't work because of the missing policy package. > But I do not find any selinux-targeted-policy rpm. > How exactly does one install this? It's selinux-policy-targeted, and it's on CD1 of the FC4 distribution, but you'd be better off installing the latest version from updates-released using yum. Do this before the relabel. Paul. From tim at birdsnest.maths.tcd.ie Sat Jan 7 15:21:24 2006 From: tim at birdsnest.maths.tcd.ie (Timothy Murphy) Date: Sat, 07 Jan 2006 15:21:24 +0000 Subject: FC4 documentation for apache + selinux ? References: <43BD2EF7.2030806@city-fan.org> <43BD3876.50904@city-fan.org> <43BE8604.3040407@redhat.com> <1136630728.28374.41.camel@laurel.intra.city-fan.org> Message-ID: Paul Howarth wrote: >> But I do not find any selinux-targeted-policy rpm. >> How exactly does one install this? > > It's selinux-policy-targeted, and it's on CD1 of the FC4 distribution, > but you'd be better off installing the latest version from > updates-released using yum. Do this before the relabel. Thanks very much for your continuing patience. In self-defence, I might say that you (or perhaps another guru) gave the wrong name: > If you want to turn > on SELinux, you need to install selinux-targeted-policy But my last question before turning selinux on - are the firewall and selinux parts of system-config-securitylevel completely independent? In other words, can I continue to use shorewall (by clicking on "Disable firewall" in the "Firewall Options" tab in system-config-securitylevel) and still run selinux? -- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From paul at city-fan.org Sat Jan 7 19:13:28 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 07 Jan 2006 19:13:28 +0000 Subject: FC4 documentation for apache + selinux ? In-Reply-To: References: <43BD2EF7.2030806@city-fan.org> <43BD3876.50904@city-fan.org> <43BE8604.3040407@redhat.com> <1136630728.28374.41.camel@laurel.intra.city-fan.org> Message-ID: <1136661209.28374.68.camel@laurel.intra.city-fan.org> On Sat, 2006-01-07 at 15:21 +0000, Timothy Murphy wrote: > Paul Howarth wrote: > > >> But I do not find any selinux-targeted-policy rpm. > >> How exactly does one install this? > > > > It's selinux-policy-targeted, and it's on CD1 of the FC4 distribution, > > but you'd be better off installing the latest version from > > updates-released using yum. Do this before the relabel. > > Thanks very much for your continuing patience. > In self-defence, I might say that you (or perhaps another guru) > gave the wrong name: I'm no guru, at least not here. I only earned my policy writer decoder ring six months ago :-) > > If you want to turn > > on SELinux, you need to install selinux-targeted-policy > > But my last question before turning selinux on - > are the firewall and selinux parts of system-config-securitylevel > completely independent? > > In other words, can I continue to use shorewall > (by clicking on "Disable firewall" in the "Firewall Options" tab > in system-config-securitylevel) > and still run selinux? Yes, the two are independent and you can use shorewall. Paul. From selinux at gmail.com Sat Jan 7 19:52:51 2006 From: selinux at gmail.com (Tom London) Date: Sat, 7 Jan 2006 11:52:51 -0800 Subject: Today's avcs....(readahead, hald) Message-ID: <4c4ba1530601071152yca8d319v5a8675b582d62065@mail.gmail.com> Running today's rawhide(selinux-policy-targeted-2.1.7-3), targeted/enforcing, got some avcs in messages and audit.log. I rebooted in permissive mode and: Get this in /var/log/messages (before auditd starts, I guess): ---- type=PATH msg=audit(01/07/2006 11:44:46.028:12) : item=0 name=/media/ flags=follow,directory,open inode=2289281 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/07/2006 11:44:46.028:12) : cwd=/ type=SYSCALL msg=audit(01/07/2006 11:44:46.028:12) : arch=i386 syscall=open success=yes exit=3 a0=9233228 a1=18800 a2=261158 a3=92331e8 items=1 pid=2532 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hal-system-stor exe=/bin/bash type=AVC msg=audit(01/07/2006 11:44:46.028:12) : avc: denied { read } for pid=2532 comm=hal-system-stor name=media dev=dm-0 ino=2289281 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir ---- type=PATH msg=audit(01/07/2006 11:44:50.152:13) : item=0 name=/boot flags=follow inode=2 dev=03:02 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/07/2006 11:44:50.152:13) : cwd=/ type=AVC_PATH msg=audit(01/07/2006 11:44:50.152:13) : path=/boot type=SYSCALL msg=audit(01/07/2006 11:44:50.152:13) : arch=i386 syscall=stat64 success=yes exit=0 a0=bfd80ede a1=bfd80e5c a2=359ff4 a3=303 items=1 pid=2527 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hald exe=/usr/sbin/hald type=AVC msg=audit(01/07/2006 11:44:50.152:13) : avc: denied { getattr } for pid=2527 comm=hald name=/ dev=hda2 ino=2 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir ---- type=PATH msg=audit(01/07/2006 11:44:50.152:14) : item=0 name=/proc/sys/fs/binfmt_misc flags=follow inode=4808 dev=00:13 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/07/2006 11:44:50.152:14) : cwd=/ type=SYSCALL msg=audit(01/07/2006 11:44:50.152:14) : arch=i386 syscall=stat64 success=yes exit=0 a0=bfd80ed9 a1=bfd80e5c a2=359ff4 a3=303 items=1 pid=2527 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hald exe=/usr/sbin/hald type=AVC msg=audit(01/07/2006 11:44:50.152:14) : avc: denied { search } for pid=2527 comm=hald name=fs dev=proc ino=-268435429 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:sysctl_fs_t:s0 tclass=dir ---- type=PATH msg=audit(01/07/2006 11:44:50.152:15) : item=0 name=/var/lib/nfs/rpc_pipefs flags=follow inode=5930 dev=00:14 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/07/2006 11:44:50.152:15) : cwd=/ type=SYSCALL msg=audit(01/07/2006 11:44:50.152:15) : arch=i386 syscall=stat64 success=yes exit=0 a0=bfd80edb a1=bfd80e5c a2=359ff4 a3=303 items=1 pid=2527 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hald exe=/usr/sbin/hald type=AVC msg=audit(01/07/2006 11:44:50.152:15) : avc: denied { search } for pid=2527 comm=hald name=nfs dev=dm-0 ino=2142222 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:var_lib_nfs_t:s0 tclass=dir ---- type=PATH msg=audit(01/07/2006 11:45:00.837:17) : item=0 name=/var/lib/nfs/rpc_pipefs flags=follow inode=5930 dev=00:14 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/07/2006 11:45:00.837:17) : cwd=/ type=SYSCALL msg=audit(01/07/2006 11:45:00.837:17) : arch=i386 syscall=stat64 success=yes exit=0 a0=bfd8105b a1=bfd80fdc a2=359ff4 a3=bfd8105e items=1 pid=2527 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hald exe=/usr/sbin/hald type=AVC msg=audit(01/07/2006 11:45:00.837:17) : avc: denied { search } for pid=2527 comm=hald name=nfs dev=dm-0 ino=2142222 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:var_lib_nfs_t:s0 tclass=dir ---- type=PATH msg=audit(01/07/2006 11:45:40.036:25) : item=1 flags=follow,open inode=327257 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 type=PATH msg=audit(01/07/2006 11:45:40.036:25) : item=0 name=/usr/bin/skype flags=follow,open inode=145693 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/07/2006 11:45:40.036:25) : cwd=/home/tbl type=SYSCALL msg=audit(01/07/2006 11:45:40.036:25) : arch=i386 syscall=execve success=yes exit=0 a0=9126db0 a1=bffa9740 a2=9114078 a3=0 items=2 pid=2857 auid=unknown(4294967295) uid=tbl gid=tbl euid=tbl suid=tbl fsuid=tbl egid=tbl sgid=tbl fsgid=tbl comm=skype exe=/usr/bin/skype type=AVC msg=audit(01/07/2006 11:45:40.036:25) : avc: granted { execmem } for pid=2857 comm=skype scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process type=AVC msg=audit(01/07/2006 11:45:40.036:25) : avc: granted { execmem } for pid=2857 comm=skype scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process ---- type=PATH msg=audit(01/07/2006 11:45:41.792:26) : item=0 name=/media/disk flags=parent inode=2289281 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/07/2006 11:45:41.792:26) : cwd=/ type=SYSCALL msg=audit(01/07/2006 11:45:41.792:26) : arch=i386 syscall=mkdir success=yes exit=0 a0=bfa31919 a1=1ff a2=804e1b8 a3=bfa31919 items=1 pid=2871 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=mkdir exe=/bin/mkdir type=AVC msg=audit(01/07/2006 11:45:41.792:26) : avc: denied { create } for pid=2871 comm=mkdir name=disk scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir type=AVC msg=audit(01/07/2006 11:45:41.792:26) : avc: denied { add_name } for pid=2871 comm=mkdir name=disk scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir type=AVC msg=audit(01/07/2006 11:45:41.792:26) : avc: denied { write } for pid=2871 comm=mkdir name=media dev=dm-0 ino=2289281 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir ---- type=PATH msg=audit(01/07/2006 11:45:41.868:27) : item=0 name=/media/disk/.created-by-hal flags=parent,open,create inode=2289299 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/07/2006 11:45:41.868:27) : cwd=/ type=SYSCALL msg=audit(01/07/2006 11:45:41.868:27) : arch=i386 syscall=open success=yes exit=0 a0=bff77909 a1=8941 a2=1b6 a3=8941 items=1 pid=2872 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=touch exe=/bin/touch type=AVC msg=audit(01/07/2006 11:45:41.868:27) : avc: denied { create } for pid=2872 comm=touch name=.created-by-hal scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=file ---- type=PATH msg=audit(01/07/2006 11:45:41.868:28) : item=0 name=/proc/self/fd/0 flags=follow inode=2289300 dev=fd:00 mode=file,644 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/07/2006 11:45:41.868:28) : cwd=/ type=SYSCALL msg=audit(01/07/2006 11:45:41.868:28) : arch=i386 syscall=utimes success=yes exit=0 a0=bff772c0 a1=0 a2=8ecff4 a3=0 items=1 pid=2872 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=touch exe=/bin/touch type=AVC msg=audit(01/07/2006 11:45:41.868:28) : avc: denied { write } for pid=2872 comm=touch name=.created-by-hal dev=dm-0 ino=2289300 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=file ---- type=PATH msg=audit(01/07/2006 11:45:42.136:29) : item=0 name=/media/disk flags=parent inode=2289281 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/07/2006 11:45:42.136:29) : cwd=/ type=SYSCALL msg=audit(01/07/2006 11:45:42.136:29) : arch=i386 syscall=rmdir success=no exit=-39(Directory not empty) a0=bffe1919 a1=0 a2=804c80c a3=bffe1919 items=1 pid=2877 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=rmdir exe=/bin/rmdir type=AVC msg=audit(01/07/2006 11:45:42.136:29) : avc: denied { rmdir } for pid=2877 comm=rmdir name=disk dev=dm-0 ino=2289299 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir type=AVC msg=audit(01/07/2006 11:45:42.136:29) : avc: denied { remove_name } for pid=2877 comm=rmdir name=disk dev=dm-0 ino=2289299 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir ---- type=SYSCALL msg=audit(01/07/2006 11:45:46.992:30) : arch=i386 syscall=mprotect success=yes exit=0 a0=bfcd5000 a1=1000 a2=1000007 a3=fffff000 items=0 pid=2862 auid=unknown(4294967295) uid=tbl gid=tbl euid=tbl suid=tbl fsuid=tbl egid=tbl sgid=tbl fsgid=tbl comm=gaim exe=/usr/bin/gaim type=AVC msg=audit(01/07/2006 11:45:46.992:30) : avc: granted { execmem } for pid=2862 comm=gaim scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process tom -- Tom London From selinux at gmail.com Sun Jan 8 00:26:18 2006 From: selinux at gmail.com (Tom London) Date: Sat, 7 Jan 2006 16:26:18 -0800 Subject: Today's avcs....(readahead, hald) In-Reply-To: <4c4ba1530601071152yca8d319v5a8675b582d62065@mail.gmail.com> References: <4c4ba1530601071152yca8d319v5a8675b582d62065@mail.gmail.com> Message-ID: <4c4ba1530601071626uf86475cm4862fb5bb51f5ed8@mail.gmail.com> Forgot to paste in the avcs from /var/log/messages: Jan 7 11:44:23 localhost kernel: audit(1136663017.549:3): avc: granted { execmem } for pid=1603 comm="kudzu" scontext=system_u:system_r:kudzu_t:s0 tcontext=system_u:system_r:kudzu_t:s0 tclass=process Jan 7 11:44:23 localhost kernel: audit(1136663018.325:4): avc: denied { search } for pid=1594 comm="readahead" name="/" dev=ramfs ino=4548 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=dir Jan 7 11:44:23 localhost kernel: audit(1136663018.325:5): avc: denied { read } for pid=1594 comm="readahead" name="display" dev=ramfs ino=4589 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=file Jan 7 11:44:23 localhost kernel: audit(1136663018.325:6): avc: denied { getattr } for pid=1594 comm="readahead" name="display" dev=ramfs ino=4589 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=file Jan 7 11:44:23 localhost kernel: audit(1136663018.325:7): avc: denied { read } for pid=1594 comm="readahead" name="rhgb-console" dev=ramfs ino=4636 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=fifo_file Jan 7 11:44:23 localhost kernel: audit(1136663018.325:8): avc: denied { getattr } for pid=1594 comm="readahead" name="rhgb-console" dev=ramfs ino=4636 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=fifo_file From tim at birdsnest.maths.tcd.ie Sun Jan 8 01:24:59 2006 From: tim at birdsnest.maths.tcd.ie (Timothy Murphy) Date: Sun, 08 Jan 2006 01:24:59 +0000 Subject: FC4 documentation for apache + selinux ? References: <43BD2EF7.2030806@city-fan.org> <43BD3876.50904@city-fan.org> <43BE8604.3040407@redhat.com> <1136630728.28374.41.camel@laurel.intra.city-fan.org> <1136661209.28374.68.camel@laurel.intra.city-fan.org> Message-ID: Paul Howarth wrote: >> But my last question before turning selinux on - >> are the firewall and selinux parts of system-config-securitylevel >> completely independent? >> >> In other words, can I continue to use shorewall >> (by clicking on "Disable firewall" in the "Firewall Options" tab >> in system-config-securitylevel) >> and still run selinux? > > Yes, the two are independent and you can use shorewall. Thanks for all your help - greatly appreciated. I realised after "yumming" for selinux\* that there was an selinux-doc rpm which I had not installed. I've been looking at these docs, but I did not find them very instructive. They reminded me a bit of sendmail. I'll see if I can find an selinux tutorial for dummies. -- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From christofer.c.bell at gmail.com Sun Jan 8 02:11:41 2006 From: christofer.c.bell at gmail.com (Christofer C. Bell) Date: Sat, 7 Jan 2006 20:11:41 -0600 Subject: FC4 documentation for apache + selinux ? In-Reply-To: References: <43BD2EF7.2030806@city-fan.org> <43BD3876.50904@city-fan.org> <43BE8604.3040407@redhat.com> <1136630728.28374.41.camel@laurel.intra.city-fan.org> <1136661209.28374.68.camel@laurel.intra.city-fan.org> Message-ID: <143f0f6c0601071811u59f09689macbecfd71743c16@mail.gmail.com> On 1/7/06, Timothy Murphy wrote: > > I'll see if I can find an selinux tutorial for dummies. I've found the Enterprise Linux documentation pretty helpful. Here's a link to it: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -- Chris "I trust the Democrats to take away my money, which I can afford. I trust the Republicans to take away my freedom, which I cannot." From dragoran at feuerpokemon.de Sun Jan 8 09:28:21 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 08 Jan 2006 10:28:21 +0100 Subject: need help getting initng works with selinux Message-ID: <43C0DB35.1050900@feuerpokemon.de> after hacking the initng source code I got it to load the policy but still have one problem: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459#c166 /sbin/ining is labeled as init_exec_t whats wrong with it? From sds at tycho.nsa.gov Mon Jan 9 14:07:55 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 09 Jan 2006 09:07:55 -0500 Subject: FC4 documentation for apache + selinux ? In-Reply-To: References: <43BD2EF7.2030806@city-fan.org> <43BD3876.50904@city-fan.org> <43BE8604.3040407@redhat.com> <1136630728.28374.41.camel@laurel.intra.city-fan.org> <1136661209.28374.68.camel@laurel.intra.city-fan.org> Message-ID: <1136815675.19934.22.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2006-01-08 at 01:24 +0000, Timothy Murphy wrote: > I realised after "yumming" for selinux\* that there was > an selinux-doc rpm which I had not installed. > I've been looking at these docs, > but I did not find them very instructive. > They reminded me a bit of sendmail. > > I'll see if I can find an selinux tutorial for dummies. http://selinux.sourceforge.net/resources.php3 has some links to useful resources. Unfortunately, the documentation all lags behind the current state of the art. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Jan 9 14:21:35 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 09 Jan 2006 09:21:35 -0500 Subject: need help getting initng works with selinux In-Reply-To: <43C0DB35.1050900@feuerpokemon.de> References: <43C0DB35.1050900@feuerpokemon.de> Message-ID: <1136816495.19934.33.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2006-01-08 at 10:28 +0100, dragoran wrote: > after hacking the initng source code I got it to load the policy but > still have one problem: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459#c166 > /sbin/ining is labeled as init_exec_t > whats wrong with it? A couple of points: 1) Please resync your -selinux patch against the latest sysvinit-selinux.patch in the Fedora Core CVS tree (or from the devel srpm). All of the initial policy loading logic has been moved into libselinux, encapsulated within the selinux_init_load_policy() function. 2) Make sure that initng re-exec's itself after a successful call to that function. Otherwise, it won't transition into its own domain. -- Stephen Smalley National Security Agency From lamont at gurulabs.com Mon Jan 9 18:51:32 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Mon, 9 Jan 2006 11:51:32 -0700 Subject: Postfix virtual and Dovecot In-Reply-To: <1136578251.28374.24.camel@laurel.intra.city-fan.org> References: <43BEC204.6040309@mailforest.com> <1136578251.28374.24.camel@laurel.intra.city-fan.org> Message-ID: <200601091151.37425.lamont@gurulabs.com> On Friday 06 January 2006 01:10pm, Paul Howarth wrote: > On Fri, 2006-01-06 at 14:16 -0500, Karyl F. Stein wrote: > > Any ideas on how I can get the Postfix virtual transport to deliver to a > > maildir and have Dovecot pick it up? I can get one or the other to > > work, but not both. The maildirs are in /srv/mirror/mail. If I make > > that directory have the postfix_spool_t context, Postfix writes there > > fine, but Dovecot can't access it. If I make the directory have > > mail_spool_t, then Dovecot can access it, but Postfix can't. As far as > > I can tell, there doesn't seem to be a common context. > > > > I'm running FC4 with the targeted policy. > > Perhaps postfix works differently to sendmail but I use procmail to > deliver mail received by sendmail to maildirs under /var/spool/mail, > which is mail_spool_t and hence works fine with dovecot. Well, Postfix does work differently from Sendmail...but I don't think that has much to do with his problem here. Also, either maildrop or procmail (or both, if you really want to go nuts) can be used with either Postfix or Sendmail...they do the same thing. I like maildrop better, myself, because it seems to work with less overhead than procmail (I've never done benchmarks, so this is just one of those seems-to-my-gut kinda things) and because the syntax for the ~/.mailfilter files is less cryptic than procmail recipes; it's much easier for new users to learn and be comfortable. > (having just looked at the policy sources, the one for postfix is vastly > more complicated than the sendmail one so it does indeed appear to be > different...) Yeah, I don't know why there seems to be no real overlap in the Sendmail & Postfix policies, though I can guess. I'm wondering if there needs to be a common type. mail_spool_t would seem to fit the bill, but I haven't really looked too closely at this one. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lamont at gurulabs.com Mon Jan 9 18:58:56 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Mon, 9 Jan 2006 11:58:56 -0700 Subject: Postfix virtual and Dovecot In-Reply-To: <43BF423C.1010107@mailforest.com> References: <43BEC204.6040309@mailforest.com> <1136582105.31349.10.camel@rousalka.dyndns.org> <43BF423C.1010107@mailforest.com> Message-ID: <200601091159.00404.lamont@gurulabs.com> On Friday 06 January 2006 09:23pm, Karyl F. Stein wrote: > Nicolas Mailhot wrote: > >I use this : > > > >I. In /etc/postfix/main.cf > > > >mailbox_command = /usr/bin/procmail > > > >II. In /etc/procmailrc > > > >MAILDIR=$HOME/.maildir > >DEFAULT=./ > >LOGFILE=$MAILDIR/logfile > > > >and if you want > > > >SPAM=.Spam.Auto/ > > > >:0fw: .spamc.lock > > > >* < 256000 > > > >| spamc > >| > >:0 > > > >* ^X-Spam-Status: Yes > >$SPAM > > > >III. In /etc/dovecot.conf > >default_mail_env = maildir:%h/.maildir > > > >Regards, > > Thanks, Nicolas. My email users do not have UNIX accounts, which makes > things a little more difficult. Both maildrop and procmail are configured using a file in the user's home directory. Perhaps what you need for your users is Sieve, which has a nice client/server protocol for editing filtering rules and has a nice web front-end that is actually reasonably usable (for a web interface) so even users who don't understand how to write a regex can make good useful rules. One thing odd about that web interface...it only seems to pickup new IMAP folders during login...if I add a new folder to my IMAP store, then I have to log out and log back in AFTER my email client actually communicates with the IMAP server and really creates the new IMAP folder on the server. Sieve comes as part of the Cyrus IMAP server, so you would have to switch. it's a little more work to stand up than Dovecot, but it's not bad at all. > However, your suggestion of using an > alternate transport brought me to maildrop. It looks like maildrop > might work nicely for what I need and seems to be documented in > Postfix. However, I'd rather not install another layer of complexity if > possible. Can you do something like create a "local" policy that won't > be overwritten when a new targeted policy RPM is released? That way I > could configure Postfix to have write access to mail_spool_t. Like I said in my other reply, this was my first thought. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From karyl.lists at mailforest.com Mon Jan 9 23:44:09 2006 From: karyl.lists at mailforest.com (Karyl F. Stein) Date: Mon, 09 Jan 2006 18:44:09 -0500 Subject: Postfix virtual and Dovecot In-Reply-To: <200601091151.37425.lamont@gurulabs.com> References: <43BEC204.6040309@mailforest.com> <1136578251.28374.24.camel@laurel.intra.city-fan.org> <200601091151.37425.lamont@gurulabs.com> Message-ID: <43C2F549.1040900@mailforest.com> Lamont R. Peterson wrote: >>Perhaps postfix works differently to sendmail but I use procmail to >>deliver mail received by sendmail to maildirs under /var/spool/mail, >>which is mail_spool_t and hence works fine with dovecot. >> >> > >Well, Postfix does work differently from Sendmail...but I don't think that has >much to do with his problem here. > >Also, either maildrop or procmail (or both, if you really want to go nuts) can >be used with either Postfix or Sendmail...they do the same thing. I like >maildrop better, myself, because it seems to work with less overhead than >procmail (I've never done benchmarks, so this is just one of those >seems-to-my-gut kinda things) and because the syntax for the ~/.mailfilter >files is less cryptic than procmail recipes; it's much easier for new users >to learn and be comfortable. > > I got maildrop working with courier-authlib to query the LDAP and deliver the mail to the correct maildir. If I call maildir from the command line it works great with Dovecot. However, it doesn't work through Postfix. I changed the maildrop context to postfix_pipe_exec_t so Postfix could call it. The problem is that maildrop is now being blocked from accessing the named pipe (tclass=sock_file) that courier-authlib creates. (I need courier-authlib because the LDAP code now resides in there only.) I tried to change the pipe's context to something like postfix_pipe_t, but am blocked from doing that. >>(having just looked at the policy sources, the one for postfix is vastly >>more complicated than the sendmail one so it does indeed appear to be >>different...) >> >> > >Yeah, I don't know why there seems to be no real overlap in the Sendmail & >Postfix policies, though I can guess. I'm wondering if there needs to be a >common type. mail_spool_t would seem to fit the bill, but I haven't really >looked too closely at this one. > > This would fix my problems and seems to be pretty clean. For now, I think I'm throwing in the towel on getting this to work. Thanks, Karyl From maschino at jouy.inra.fr Tue Jan 10 09:49:34 2006 From: maschino at jouy.inra.fr (Emeric Maschino) Date: Tue, 10 Jan 2006 10:49:34 +0100 Subject: Denied { search } mingetty and can't log in Message-ID: <1136886574.5079.29.camel@localhost.localdomain> Hi, I've just installed a clean Fedora Core development IA-64 (Itanium systems) on the second HDD of my hp workstation zx6000. During the installation of selinux-policy-targeted 2.1.7-3, the following messages are recorded in the logs. I don't know if they're relevant to my problem with mingetty however (see below): libsemanage.dbase_policydb_list: out of memory libsemanage.semanage_exec_prog: Child process /usr/sbin/genhomedircon did not exit cleanly. libsemanage.semanage_install_sandbox: genhomedircon returned error code -1. semodule: Failed! Forcing reinstall or trying to install a different policy (e.g. selinux- policy-mls) gives the same result. At reboot, I can't log in to my system because of something going wrong with mingetty. The following line is repeated a huge number of times: avc: denied { search } for pid=553 comm="mingetty" name="/" dev=tmpfs ino=977 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir Relabeling the whole file system with touch /.autorelabel or fixfiles relabel didn't help. Sure, I can log in in permissive mode. I can't see the message regarding mingetty, but I'm getting a few other denials. If it can help understanding what's going wrong, here they are: avc: denied { execmod } for pid=380 comm="rc.sysinit" name="bash" dev=dm-0 ino=3371812 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file avc: denied { execmod } for pid=389 comm="awk" name="gawk" dev=dm-0 ino=3371818 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file avc: denied { execmod } for pid=409 comm="start_udev" name="bash" dev=dm-0 ino=3371812 scontext=system_u:system_r:udev_t:s0-s0:c0.c255 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file avc: denied { execmod } for pid=412 comm="awk" name="gawk" dev=dm-0 ino=3371818 scontext=system_u:system_r:udev_t:s0-s0:c0.c255 tcontext=system_u:object_r:bin_t:s0 tclass=file avc: denied { execmod } for pid=559 comm="sh" name="bash" dev=dm-0 ino=3371812 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file avc: denied { execmod } for pid=1519 comm="S10network" name="bash" dev=dm-0 ino=3371812 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file avc: denied { execmod } for pid=1607 comm="awk" name="gawk" dev=dm-0 ino=3371818 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file avc: denied { execmod } for pid=1728 comm="dhclient-script" name="bash" dev=dm-0 ino=3371812 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file avc: denied { execmod } for pid=1741 comm="awk" name="gawk" dev=dm-0 ino=3371818 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file I'm running kernel 2.6.15-1.1826.2.5_FC5 with the following SELinux components: checkpolicy 1.28-4, libselinux 1.29.4-1, libsepol 1.11.7-1, libsetrans 0.1.15-1, selinux-policy 2.1.7-3 and selinux-policy-targeted 2.1.7-3 (hope I don't forget one). If I can try something to help correct these problems on the IA-64 architecture, just let me know. Thanks, ?meric From selinux at gmail.com Tue Jan 10 15:59:12 2006 From: selinux at gmail.com (Tom London) Date: Tue, 10 Jan 2006 07:59:12 -0800 Subject: more on readahead/hal Message-ID: <4c4ba1530601100759o1b3eaf90s13b1e41e32ea6d34@mail.gmail.com> Today's rawhide, targeted/enforcing. [Reporting this since build log indicated fixes for hal/readahead. Sorry if I am jumping the gun....] hal issues: ---- type=PATH msg=audit(01/10/2006 07:18:22.011:13) : item=0 name=/media/disk/.created-by-hal flags=follow inode=2289300 dev=fd:00 mode=file,644 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/10/2006 07:18:22.011:13) : cwd=/ type=AVC_PATH msg=audit(01/10/2006 07:18:22.011:13) : path=/media/disk/.created-by-hal type=SYSCALL msg=audit(01/10/2006 07:18:22.011:13) : arch=i386 syscall=stat64 success=no exit=-13(Permission denied) a0=870f008 a1=bf9ee1b8 a2=25cff4 a3=870f5a8 items=1 pid=2512 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hal-system-stor exe=/bin/bash type=AVC msg=audit(01/10/2006 07:18:22.011:13) : avc: denied { getattr } for pid=2512 comm=hal-system-stor name=.created-by-hal dev=dm-0 ino=2289300 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=file ---- type=PATH msg=audit(01/10/2006 07:18:22.027:14) : item=0 name=/media/disk-1/.created-by-hal flags=follow inode=2289302 dev=fd:00 mode=file,644 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/10/2006 07:18:22.027:14) : cwd=/ type=AVC_PATH msg=audit(01/10/2006 07:18:22.027:14) : path=/media/disk-1/.created-by-hal type=SYSCALL msg=audit(01/10/2006 07:18:22.027:14) : arch=i386 syscall=stat64 success=no exit=-13(Permission denied) a0=870f588 a1=bf9ee1b8 a2=25cff4 a3=870f008 items=1 pid=2512 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hal-system-stor exe=/bin/bash type=AVC msg=audit(01/10/2006 07:18:22.027:14) : avc: denied { getattr } for pid=2512 comm=hal-system-stor name=.created-by-hal dev=dm-0 ino=2289302 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=file ---- type=PATH msg=audit(01/10/2006 07:18:22.059:15) : item=0 name=/media/disk-2/.created-by-hal flags=follow inode=2289314 dev=fd:00 mode=file,644 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/10/2006 07:18:22.059:15) : cwd=/ type=AVC_PATH msg=audit(01/10/2006 07:18:22.059:15) : path=/media/disk-2/.created-by-hal type=SYSCALL msg=audit(01/10/2006 07:18:22.059:15) : arch=i386 syscall=stat64 success=no exit=-13(Permission denied) a0=870f688 a1=bf9ee1b8 a2=25cff4 a3=870f008 items=1 pid=2512 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hal-system-stor exe=/bin/bash type=AVC msg=audit(01/10/2006 07:18:22.059:15) : avc: denied { getattr } for pid=2512 comm=hal-system-stor name=.created-by-hal dev=dm-0 ino=2289314 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=file ---- type=PATH msg=audit(01/10/2006 07:18:24.972:16) : item=0 name=/boot flags=follow inode=2 dev=03:02 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/10/2006 07:18:24.972:16) : cwd=/ type=AVC_PATH msg=audit(01/10/2006 07:18:24.972:16) : path=/boot type=SYSCALL msg=audit(01/10/2006 07:18:24.972:16) : arch=i386 syscall=stat64 success=no exit=-13(Permission denied) a0=bff484ce a1=bff4844c a2=258ff4 a3=303 items=1 pid=2507 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hald exe=/usr/sbin/hald type=AVC msg=audit(01/10/2006 07:18:24.972:16) : avc: denied { getattr } for pid=2507 comm=hald name=/ dev=hda2 ino=2 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir ---- type=PATH msg=audit(01/10/2006 07:18:25.076:17) : item=0 name=/boot flags=follow inode=2 dev=03:02 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/10/2006 07:18:25.076:17) : cwd=/ type=AVC_PATH msg=audit(01/10/2006 07:18:25.076:17) : path=/boot type=SYSCALL msg=audit(01/10/2006 07:18:25.076:17) : arch=i386 syscall=stat64 success=no exit=-13(Permission denied) a0=bff484ce a1=bff4844c a2=258ff4 a3=302 items=1 pid=2507 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hald exe=/usr/sbin/hald type=AVC msg=audit(01/10/2006 07:18:25.076:17) : avc: denied { getattr } for pid=2507 comm=hald name=/ dev=hda2 ino=2 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir ---- type=PATH msg=audit(01/10/2006 07:18:25.228:18) : item=0 name=/boot flags=follow inode=2 dev=03:02 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/10/2006 07:18:25.228:18) : cwd=/ type=AVC_PATH msg=audit(01/10/2006 07:18:25.228:18) : path=/boot type=SYSCALL msg=audit(01/10/2006 07:18:25.228:18) : arch=i386 syscall=stat64 success=no exit=-13(Permission denied) a0=bff484ce a1=bff4844c a2=258ff4 a3=301 items=1 pid=2507 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hald exe=/usr/sbin/hald type=AVC msg=audit(01/10/2006 07:18:25.228:18) : avc: denied { getattr } for pid=2507 comm=hald name=/ dev=hda2 ino=2 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir ---- type=PATH msg=audit(01/10/2006 07:18:31.368:20) : item=0 name=/boot flags=follow inode=2 dev=03:02 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/10/2006 07:18:31.368:20) : cwd=/ type=AVC_PATH msg=audit(01/10/2006 07:18:31.368:20) : path=/boot type=SYSCALL msg=audit(01/10/2006 07:18:31.368:20) : arch=i386 syscall=stat64 success=no exit=-13(Permission denied) a0=bff4864e a1=bff485cc a2=258ff4 a3=301 items=1 pid=2507 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hald exe=/usr/sbin/hald type=AVC msg=audit(01/10/2006 07:18:31.368:20) : avc: denied { getattr } for pid=2507 comm=hald name=/ dev=hda2 ino=2 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir ---- type=PATH msg=audit(01/10/2006 07:19:16.279:31) : item=0 name=/media/disk-3/.created-by-hal flags=parent,open,create inode=2289282 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/10/2006 07:19:16.279:31) : cwd=/ type=SYSCALL msg=audit(01/10/2006 07:19:16.279:31) : arch=i386 syscall=open success=no exit=-13(Permission denied) a0=bfc0b888 a1=8941 a2=1b6 a3=8941 items=1 pid=2837 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=touch exe=/bin/touch type=AVC msg=audit(01/10/2006 07:19:16.279:31) : avc: denied { create } for pid=2837 comm=touch name=.created-by-hal scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=file ---- type=PATH msg=audit(01/10/2006 07:19:22.523:32) : item=0 name=/media/disk-3/.created-by-hal flags=parent,open,create inode=2289282 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/10/2006 07:19:22.523:32) : cwd=/ type=SYSCALL msg=audit(01/10/2006 07:19:22.523:32) : arch=i386 syscall=open success=no exit=-13(Permission denied) a0=bfdad851 a1=8941 a2=1b6 a3=8941 items=1 pid=2850 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=touch exe=/bin/touch type=AVC msg=audit(01/10/2006 07:19:22.523:32) : avc: denied { create } for pid=2850 comm=touch name=.created-by-hal scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=file ---- type=PATH msg=audit(01/10/2006 07:19:22.531:33) : item=0 name=/boot flags=follow inode=2 dev=03:02 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/10/2006 07:19:22.531:33) : cwd=/ type=AVC_PATH msg=audit(01/10/2006 07:19:22.531:33) : path=/boot type=SYSCALL msg=audit(01/10/2006 07:19:22.531:33) : arch=i386 syscall=stat64 success=no exit=-13(Permission denied) a0=bff4864e a1=bff485cc a2=258ff4 a3=301 items=1 pid=2507 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hald exe=/usr/sbin/hald type=AVC msg=audit(01/10/2006 07:19:22.531:33) : avc: denied { getattr } for pid=2507 comm=hald name=/ dev=hda2 ino=2 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir ---- type=PATH msg=audit(01/10/2006 07:19:22.531:34) : item=0 name=/media/disk-3 flags=follow inode=2 dev=03:02 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/10/2006 07:19:22.531:34) : cwd=/ type=AVC_PATH msg=audit(01/10/2006 07:19:22.531:34) : path=/media/disk-3 type=SYSCALL msg=audit(01/10/2006 07:19:22.531:34) : arch=i386 syscall=stat64 success=no exit=-13(Permission denied) a0=bff4864e a1=bff485cc a2=258ff4 a3=301 items=1 pid=2507 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hald exe=/usr/sbin/hald type=AVC msg=audit(01/10/2006 07:19:22.531:34) : avc: denied { getattr } for pid=2507 comm=hald name=/ dev=hda2 ino=2 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir ---- Still have problems with readahead. From /var/log/messages: Jan 10 07:18:01 localhost kernel: audit(1136906246.537:4): avc: denied { search } for pid=1570 comm="readahead" name="/" dev=ramfs ino=4195 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=dir Jan 10 07:18:01 localhost kernel: audit(1136906246.537:5): avc: denied { search } for pid=1570 comm="readahead" name="/" dev=ramfs ino=4195 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=dir Jan 10 07:18:01 localhost kernel: audit(1136906246.537:6): avc: denied { search } for pid=1570 comm="readahead" name="/" dev=ramfs ino=4195 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=dir Jan 10 07:18:01 localhost kernel: audit(1136906254.213:7): avc: denied { search } for pid=1570 comm="readahead" name="/" dev=ramfs ino=4195 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=dir Jan 10 07:18:01 localhost kernel: audit(1136906254.213:8): avc: denied { search } for pid=1570 comm="readahead" name="/" dev=ramfs ino=4195 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=dir Jan 10 07:18:01 localhost kernel: audit(1136906254.213:9): avc: denied { search } for pid=1570 comm="readahead" name="/" dev=ramfs ino=4195 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=dir -- Tom London From selinux at gmail.com Wed Jan 11 15:06:49 2006 From: selinux at gmail.com (Tom London) Date: Wed, 11 Jan 2006 07:06:49 -0800 Subject: more on readahead/hal In-Reply-To: <4c4ba1530601100759o1b3eaf90s13b1e41e32ea6d34@mail.gmail.com> References: <4c4ba1530601100759o1b3eaf90s13b1e41e32ea6d34@mail.gmail.com> Message-ID: <4c4ba1530601110706t69952c1cg51ec7408e51ae7b0@mail.gmail.com> Today's updated targeted fixes hal problem, thanks! (This appears to fix a problem where hal mounted /boot twice: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177468) The following AVCs remain in /var/log/messages. Appears that readahead is trying to access /etc/rhgb/temp/display and /etc/rhgb/temp/rhgb-console. No apparent impact on system. tom Jan 11 06:48:23 localhost kernel: ip_tables: (C) 2000-2002 Netfilter core team Jan 11 06:48:23 localhost kernel: audit(1136990871.541:4): avc: denied { read } for pid=1573 comm="readahead" name="display" dev=ramfs ino=4241 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=file Jan 11 06:48:23 localhost kernel: audit(1136990871.541:5): avc: denied { read } for pid=1573 comm="readahead" name="rhgb-console" dev=ramfs ino=4288 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=fifo_file Jan 11 06:48:23 localhost kernel: Netfilter messages via NETLINK v0.30. Jan 11 06:48:23 localhost kernel: ip_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per conntrack Jan 11 06:48:23 localhost kernel: audit(1136990878.790:6): avc: denied { read } for pid=1573 comm="readahead" name="display" dev=ramfs ino=4241 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=file Jan 11 06:48:23 localhost kernel: audit(1136990878.794:7): avc: denied { read } for pid=1573 comm="readahead" name="rhgb-console" dev=ramfs ino=4288 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=fifo_file Jan 11 06:48:23 localhost kernel: e1000: eth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex Jan 11 06:48:23 localhost kernel: audit(1136990897.859:8): audit_backlog_limit=256 old=64 by auid=4294967295 From dravet at hotmail.com Wed Jan 11 19:56:52 2006 From: dravet at hotmail.com (Jason Dravet) Date: Wed, 11 Jan 2006 13:56:52 -0600 Subject: execmem Message-ID: When execstack was turned off on December 9 and execmem and execmod were turned off on December 10 several programs broke and I opened bugzilla issues for them. Now one of the programmers has contacted me about this, but now the program works. I am pretty sure the program was not fixed (I have not updated it) as suggested by http://people.redhat.com/drepper/selinux-mem.html. I think the selinux policy changed and allows the exec* access again. How can I turn off this access so the program can be fixed properly? I tried the following command: setsebool -P allow_execmem=0 allow_execmod=0 allow_execheap=0 and this is what I got: libsemanage.dbase_llist_set: record not found in the database libsemanage.dbase_llist_set: could not set record value Could not change policy booleans I am running selinux-policy-targeted-2.1.8-3 and selinux-policy-2.1.8-3 in enforcing mode on Fedora rawhide. Thanks, Jason From linux_4ever at yahoo.com Wed Jan 11 20:08:37 2006 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 11 Jan 2006 12:08:37 -0800 (PST) Subject: execmem In-Reply-To: Message-ID: <20060111200837.91753.qmail@web51508.mail.yahoo.com> >I think the selinux policy changed and allows the exec* access again. >How can I turn off this access so the program can be fixed properly? Which bugzilla was it? I don't think policy changes have been made for this. It will be easier for me to answer you if I know what we are talking about. :) Thanks, -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dravet at hotmail.com Wed Jan 11 20:27:35 2006 From: dravet at hotmail.com (Jason Dravet) Date: Wed, 11 Jan 2006 14:27:35 -0600 Subject: execmem In-Reply-To: <20060111200837.91753.qmail@web51508.mail.yahoo.com> Message-ID: >Which bugzilla was it? I don't think policy changes have been made for >this. It >will be easier for me to answer you if I know what we are talking about. :) > >Thanks, >-Steve https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175487 see http://bugzilla.gnome.org/show_bug.cgi?id=324730 for details about this. and https://bugzilla.mozilla.org/show_bug.cgi?id=319913 are the big ones. Thanks, Jason From linux_4ever at yahoo.com Wed Jan 11 20:43:42 2006 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 11 Jan 2006 12:43:42 -0800 (PST) Subject: execmem In-Reply-To: Message-ID: <20060111204342.51354.qmail@web51509.mail.yahoo.com> >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175487 see >http://bugzilla.gnome.org/show_bug.cgi?id=324730 for details about this. Reading this...I wonder if it was solved by: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177121 In that one the dynamic loader was the problem. If you cannot reproduce the bugs, I'd close them since they may have been solved by the above bug. If you get a recurrance of the bug, re-open it and try to get an strace of the program when you know that it is generating the entry. The strace might let us figure out where in the code to start looking. >and https://bugzilla.mozilla.org/show_bug.cgi?id=319913 Not 100% sure on this either. If its gone...I'd say handle it like the above. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dravet at hotmail.com Wed Jan 11 20:58:27 2006 From: dravet at hotmail.com (Jason Dravet) Date: Wed, 11 Jan 2006 14:58:27 -0600 Subject: execmem In-Reply-To: <20060111204342.51354.qmail@web51509.mail.yahoo.com> Message-ID: > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175487 see > >http://bugzilla.gnome.org/show_bug.cgi?id=324730 for details about this. > >Reading this...I wonder if it was solved by: >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177121 > >In that one the dynamic loader was the problem. If you cannot reproduce the >bugs, >I'd close them since they may have been solved by the above bug. If you get >a >recurrance of the bug, re-open it and try to get an strace of the program >when >you know that it is generating the entry. The strace might let us figure >out >where in the code to start looking. Since this one is fixed I will close it. > >and https://bugzilla.mozilla.org/show_bug.cgi?id=319913 > >Not 100% sure on this either. If its gone...I'd say handle it like the >above. It works, but my audit.log is full of: type=AVC msg=audit(1137011293.241:40): avc: granted { execmem } for pid=2260 comm="firefox-bin" scontext=root:system_r:unconfined_t:s0-s0:c0.c255 tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=process type=SYSCALL msg=audit(1137011293.241:40): arch=40000003 syscall=192 success=yes exit=134627328 a0=0 a1=a01000 a2=7 a3=22 items=0 pid=2260 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="firefox-bin" exe="/usr/lib/firefox-1.5/firefox-bin" type=AVC msg=audit(1137011293.241:41): avc: granted { execmem } for pid=2260 comm="firefox-bin" scontext=root:system_r:unconfined_t:s0-s0:c0.c255 tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=process type=SYSCALL msg=audit(1137011293.241:41): arch=40000003 syscall=192 success=yes exit=145117184 a0=0 a1=a01000 a2=7 a3=22 items=0 pid=2260 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="firefox-bin" exe="/usr/lib/firefox-1.5/firefox-bin" type=AVC msg=audit(1137012359.833:42): avc: granted { execmem } for pid=2260 comm="firefox-bin" scontext=root:system_r:unconfined_t:s0-s0:c0.c255 tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=process type=SYSCALL msg=audit(1137012359.833:42): arch=40000003 syscall=192 success=no exit=-1257865216 a0=0 a1=a01000 a2=7 a3=22 items=0 pid=2260 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="firefox-bin" exe="/usr/lib/firefox-1.5/firefox-bin" It would be nice if there was a human readable time and date to help group messages together. Right now I have no idea where one reboot ends and the next begins. But I am getting off topic. Which would be better silencing the AVC messages or having mozilla fix the execmem issues? If you think this should be fixed by mozilla then please add yourself to the https://bugzilla.mozilla.org/show_bug.cgi?id=319913 bug so it can be confirmed and they will hopefully work on it. Thanks, Jason From linux_4ever at yahoo.com Wed Jan 11 21:10:14 2006 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 11 Jan 2006 13:10:14 -0800 (PST) Subject: execmem In-Reply-To: Message-ID: <20060111211014.43845.qmail@web51505.mail.yahoo.com> >It would be nice if there was a human readable time and date to help group >messages together. There is...use "ausearch -m avc -i -ts 12:00:00" replacing 12:00:00 with the starting time that you want it to look for. >Right now I have no idea where one reboot ends and the next begins. Generally, you can look for DEAMON_START and DAEMON_END messages: "ausearch -m DAEMON_START,DAEMON_END -i -ts 01/01/06" replacing the date with the day or time you want to start looking from. >Which would be better silencing the AVC messages or having mozilla fix >the execmem issues? Why not get an strace and attach to bugzilla. The strace needs to be during a session that generates the avc message. The strace should have some mmaps in it. >If you think this should be fixed by mozilla then please >add yourself to the https://bugzilla.mozilla.org/show_bug.cgi?id=319913 >bug so it can be confirmed and they will hopefully work on it. I am not seeing the problem. You may be loading a plugin that has some execmem needs. We need the mmap to determine what the problem really is. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dravet at hotmail.com Wed Jan 11 21:19:14 2006 From: dravet at hotmail.com (Jason Dravet) Date: Wed, 11 Jan 2006 15:19:14 -0600 Subject: execmem In-Reply-To: <20060111211014.43845.qmail@web51505.mail.yahoo.com> Message-ID: >There is...use "ausearch -m avc -i -ts 12:00:00" replacing 12:00:00 with >the starting time that you want it to look for. I did not know about this. Thanks, >Generally, you can look for DEAMON_START and DAEMON_END messages: > >"ausearch -m DAEMON_START,DAEMON_END -i -ts 01/01/06" replacing the date >with >the day or time you want to start looking from. > > >Which would be better silencing the AVC messages or having mozilla fix > >the execmem issues? > >Why not get an strace and attach to bugzilla. The strace needs to be during >a >session that generates the avc message. The strace should have some mmaps >in it. I don't know how to use strace. It is as simple as strace /usr/lib/firefox-1.5/firefox-bin? I did that and got some output but I don't know what it means. >I am not seeing the problem. You may be loading a plugin that has some >execmem >needs. We need the mmap to determine what the problem really is. I don't have a mmap on my system. Where can I get it? Thanks, Jason From linux_4ever at yahoo.com Wed Jan 11 21:36:36 2006 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 11 Jan 2006 13:36:36 -0800 (PST) Subject: execmem In-Reply-To: Message-ID: <20060111213636.30494.qmail@web51511.mail.yahoo.com> >I don't know how to use strace. It is as simple as strace >/usr/lib/firefox-1.5/firefox-bin? I did that and got some output but I >don't know what it means. pretty close. use "strace /usr/lib/firefox-1.5/firefox-bin 2> log.txt" This will put the strace into the log.txt file. Only do enough to generate the avc. The file is likely to be large. You can send it to me personally. Use sgrubb at redhat.com. I'll look it over and see if there's anything of interest. >I don't have a mmap on my system. Where can I get it? Its a syscall. It should be in the log.txt file somewhere. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From lamont at gurulabs.com Wed Jan 11 22:01:33 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 11 Jan 2006 15:01:33 -0700 Subject: FC3 nscd AVC denied Message-ID: <200601111501.38204.lamont@gurulabs.com> All, Here's the setup ... Using authconfig to turn on nscd and setup TLS encrypted LDAP authentication & user information, the LDAP server's "server.crt" file has been copied to /etc/openldap/ on the client and the /etc/openldap/ldap.conf file got the line "TLS_CACERT /etc/openldap/server.crt" added to it. I'm using the latest nscd package for FC3 (which fixed another bug related to LDAP). Starting nscd produces these three avc denied messages (from /var/log/messages): Jan 11 09:56:52 station13 nscd: 27993 Access Vector Cache (AVC) started Jan 11 09:56:52 station13 nscd: nscd startup succeeded Jan 11 09:56:53 station13 kernel: audit(1136998613.032:0): avc: denied { read } for pid=27993 exe=/usr/sbin/nscd name=cert.pem dev=sda2 ino=738049 scontext=root:system_r:nscd_t tcontext=system_u:object_r:usr_t tclass=lnk_file Jan 11 09:56:53 station13 kernel: audit(1136998613.032:0): avc: denied { read } for pid=27993 exe=/usr/sbin/nscd name=urandom dev=tmpfs ino=935 scontext=root:system_r:nscd_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file Jan 11 09:56:53 station13 kernel: audit(1136998613.032:0): avc: denied { read } for pid=27993 exe=/usr/sbin/nscd name=random dev=tmpfs ino=934 scontext=root:system_r:nscd_t tcontext=system_u:object_r:random_device_t tclass=chr_file Also, in this configuration, logins to LDAP accounts fail; the username is unrecognized. If I shut down nscd, then LDAP account logins work again. Running "setsebool -P nscd_disable_trans 1" and then restarting nscd (i.e. "/etc/init.d/nscd restart") fixes the login problem. It appears that nscd will only attempts to open file handles to /usr/share/ssl/cert.pem which is a symlink to certs/ca-bundle.crt (both have the label system_u:object_r:usr_t) and /dev/random & /dev/urandom at startup. Examining /etc/selinux/targeted/src/policy/domains/program/nscd.te (that is the right file, yes?) in the latest selinux-policy-targeted-sources for FC3 looks like nscd_t should have access to both urandom_device_t & random_device_t: 75: allow nscd_t { urandom_device_t random_device_t }:chr_file { getattr read}; which is a little different from the originally shipped policy: 85: allow nscd_t uransom_device_t:chr_file { getattr read }; It also looks like nscd.te used to have: 86: r_dir_file(nscd_t, usr_t) but the newest policy has no lines referencing usr_t. I'm not certain that nscd actually needs to read /usr/share/ssl/cert.pem in order for TLS to work, but I can understand the need to access /dev/random and/or /dev/urandom. OK. So, I haven't done much writing of SELinux policy, and most of that was a while ago, but It looks like the original policy shouldn't have been causing these problems to begin with. What am I missing here? Oh, and BTW, this configuration works fine on a RHEL4 client without updates. which made me think that updating the FC3 selinux-policy-targeted package could fix the issue. Nope; it didn't. Thanks for all your hard work on SELinux and policy. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drepper at redhat.com Wed Jan 11 22:26:16 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 11 Jan 2006 14:26:16 -0800 Subject: execmem In-Reply-To: References: Message-ID: <43C58608.40509@redhat.com> Jason Dravet wrote: > It works, but my audit.log is full of: > type=AVC msg=audit(1137011293.241:40): avc: granted { execmem } for > pid=2260 comm="firefox-bin" firefox (or C++ code using symbol visibility in general) has problems introduced by the compiler: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175442 This is a hard problem. Until then the policy indeed relaxes the situation for firefox, thunderbird, etc -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From maschino at jouy.inra.fr Thu Jan 12 09:36:36 2006 From: maschino at jouy.inra.fr (Emeric Maschino) Date: Thu, 12 Jan 2006 10:36:36 +0100 Subject: more on readahead/hal In-Reply-To: <4c4ba1530601110706t69952c1cg51ec7408e51ae7b0@mail.gmail.com> References: <4c4ba1530601100759o1b3eaf90s13b1e41e32ea6d34@mail.gmail.com> <4c4ba1530601110706t69952c1cg51ec7408e51ae7b0@mail.gmail.com> Message-ID: <1137058596.7347.7.camel@localhost.localdomain> Hi, Are the packages synchronized for all the architectures in the development repository? Indeed, I even didn't noticed the problems you had with readahead/hal on my Itanium system (IA-64 architecture). So the today's updates (selinux-policy-{targeted}-2.1.8-3) didn't fix anything for me. Furthermore, I'm still experiencing the problems exhibited here (https://www.redhat.com/archives/fedora-selinux-list/2006- January/msg00049.html) and I don't know whether they also affect other architectures (maybe only 64-bit ones?) or not. Regards, ?meric Le mercredi 11 janvier 2006 ? 07:06 -0800, Tom London a ?crit : > Today's updated targeted fixes hal problem, thanks! (This appears to > fix a problem where hal mounted /boot twice: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177468) > > The following AVCs remain in /var/log/messages. Appears that readahead > is trying to access /etc/rhgb/temp/display and > /etc/rhgb/temp/rhgb-console. > > No apparent impact on system. > tom > > Jan 11 06:48:23 localhost kernel: ip_tables: (C) 2000-2002 Netfilter core team > Jan 11 06:48:23 localhost kernel: audit(1136990871.541:4): avc: > denied { read } for pid=1573 comm="readahead" name="display" > dev=ramfs ino=4241 scontext=system_u:system_r:readahead_t:s0 > tcontext=system_u:object_r:ramfs_t:s0 tclass=file > Jan 11 06:48:23 localhost kernel: audit(1136990871.541:5): avc: > denied { read } for pid=1573 comm="readahead" name="rhgb-console" > dev=ramfs ino=4288 scontext=system_u:system_r:readahead_t:s0 > tcontext=system_u:object_r:ramfs_t:s0 tclass=fifo_file > Jan 11 06:48:23 localhost kernel: Netfilter messages via NETLINK v0.30. > Jan 11 06:48:23 localhost kernel: ip_conntrack version 2.4 (8192 > buckets, 65536 max) - 232 bytes per conntrack > Jan 11 06:48:23 localhost kernel: audit(1136990878.790:6): avc: > denied { read } for pid=1573 comm="readahead" name="display" > dev=ramfs ino=4241 scontext=system_u:system_r:readahead_t:s0 > tcontext=system_u:object_r:ramfs_t:s0 tclass=file > Jan 11 06:48:23 localhost kernel: audit(1136990878.794:7): avc: > denied { read } for pid=1573 comm="readahead" name="rhgb-console" > dev=ramfs ino=4288 scontext=system_u:system_r:readahead_t:s0 > tcontext=system_u:object_r:ramfs_t:s0 tclass=fifo_file > Jan 11 06:48:23 localhost kernel: e1000: eth0: e1000_watchdog_task: > NIC Link is Up 100 Mbps Full Duplex > Jan 11 06:48:23 localhost kernel: audit(1136990897.859:8): > audit_backlog_limit=256 old=64 by auid=4294967295 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From sds at tycho.nsa.gov Thu Jan 12 13:07:57 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 12 Jan 2006 08:07:57 -0500 Subject: execmem In-Reply-To: References: Message-ID: <1137071277.19934.274.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-01-11 at 13:56 -0600, Jason Dravet wrote: > When execstack was turned off on December 9 and execmem and execmod were > turned off on December 10 several programs broke and I opened bugzilla > issues for them. Now one of the programmers has contacted me about this, > but now the program works. I am pretty sure the program was not fixed (I > have not updated it) as suggested by > http://people.redhat.com/drepper/selinux-mem.html. I think the selinux > policy changed and allows the exec* access again. How can I turn off this > access so the program can be fixed properly? > > I tried the following command: setsebool -P allow_execmem=0 allow_execmod=0 > allow_execheap=0 > and this is what I got: > libsemanage.dbase_llist_set: record not found in the database > libsemanage.dbase_llist_set: could not set record value > Could not change policy booleans > > I am running selinux-policy-targeted-2.1.8-3 and selinux-policy-2.1.8-3 in > enforcing mode on Fedora rawhide. Hmm...that error message needs to be more informative - only one of those booleans is undefined (allow_execheap - there is no boolean for it). -- Stephen Smalley National Security Agency From ivg2 at cornell.edu Thu Jan 12 13:08:43 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 12 Jan 2006 06:08:43 -0700 Subject: execmem In-Reply-To: <1137071277.19934.274.camel@moss-spartans.epoch.ncsc.mil> References: <1137071277.19934.274.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <43C654DB.7040300@cornell.edu> Stephen Smalley wrote: > On Wed, 2006-01-11 at 13:56 -0600, Jason Dravet wrote: > >> When execstack was turned off on December 9 and execmem and execmod were >> turned off on December 10 several programs broke and I opened bugzilla >> issues for them. Now one of the programmers has contacted me about this, >> but now the program works. I am pretty sure the program was not fixed (I >> have not updated it) as suggested by >> http://people.redhat.com/drepper/selinux-mem.html. I think the selinux >> policy changed and allows the exec* access again. How can I turn off this >> access so the program can be fixed properly? >> >> I tried the following command: setsebool -P allow_execmem=0 allow_execmod=0 >> allow_execheap=0 >> and this is what I got: >> libsemanage.dbase_llist_set: record not found in the database >> libsemanage.dbase_llist_set: could not set record value >> Could not change policy booleans >> >> I am running selinux-policy-targeted-2.1.8-3 and selinux-policy-2.1.8-3 in >> enforcing mode on Fedora rawhide. >> > > Hmm...that error message needs to be more informative - only one of > those booleans is undefined (allow_execheap - there is no boolean for > it). > I agree - unfortunately this code is polymorphed, so it is not completely trivial to print information specific to the record type. I'll try to improve some of this.. I guess I should add some print functions to the record method table. From ivg2 at cornell.edu Thu Jan 12 13:32:14 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 12 Jan 2006 06:32:14 -0700 Subject: execmem In-Reply-To: <43C654DB.7040300@cornell.edu> References: <1137071277.19934.274.camel@moss-spartans.epoch.ncsc.mil> <43C654DB.7040300@cornell.edu> Message-ID: <43C65A5E.1030803@cornell.edu> > I agree - unfortunately this code is polymorphed, so it is not > completely trivial to print information specific to the record type. > I'll try to improve some of this.. I guess I should add some print > functions to the record method table. On the other hand there's nothing stopping the setsebool program to do an exists() check before it tries to set the boolean - it's probably the more correct approach anyway, and it will get you much nicer error messages than relying on commit validation. From selinux at tremagi.org.uk Fri Jan 13 12:54:47 2006 From: selinux at tremagi.org.uk (Graham King) Date: Fri, 13 Jan 2006 12:54:47 +0000 Subject: Adjusting FC4 targetted policy to fix avc errors on bugzilla cgi scripts? Message-ID: <1137156887.4072.91.camel@oberon.tremagi.org.uk> Please can you help with my first, naive, attempt to fix an selinux problem? Following a recent yum update of a Fedora Core 4 machine, bugzilla no longer works. audit.log contained: avc: denied { execute_no_trans } for pid=811 comm="httpd" name="index.cgi" dev=dm-3 ino=227397 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file sestatus outputs: ... httpd_enable_cgi active ... But ls -Z /var/www/html/bugzilla-2.18.3/index.cgi showed that file to be of type httpd_sys_content_t, so I inferred that it needed to be changed to httpd_sys_script_exec_t. In order for the change to persist across relabelling events, I first tried to alter the policy by adding the following line to /etc/linux/targetted/src/policy/file_contexts/file_contexts: /var/www/html/bugzilla-[^/]*/[^/]*\.cgi -- system_u:object_r:httpd_sys_script_exec_t and then ran: cd /etc/linux/targetted/src/policy make reload make relabel ( first with setenforce 1, then with setenforce 0 ) The ls -Z output was unchanged, so I then ran: chcon -t httpd_sys_script_exec_t /var/www/html/bugzilla-2.18.3/index.cgi audit.log is however still showing the same error (adjusted for the new tcontext type). What am I doing wrong? kind regards -- Graham King From selinux at gmail.com Fri Jan 13 15:59:33 2006 From: selinux at gmail.com (Tom London) Date: Fri, 13 Jan 2006 07:59:33 -0800 Subject: logwatch avcs Message-ID: <4c4ba1530601130759s4b3502e5j71efdbd95b6d40c@mail.gmail.com> Running latest rawhide (selinux-policy-targeted-2.1.9-2), targeted/enforcing. Should sbin_t:lnk_file included in corecmd_read_sbin_file(), ....? type=PATH msg=audit(01/13/2006 07:39:38.361:43) : item=0 name=/selinux flags=follow inode=327 dev=00:0d mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/13/2006 07:39:38.361:43) : cwd=/ type=AVC_PATH msg=audit(01/13/2006 07:39:38.361:43) : path=/selinux type=SYSCALL msg=audit(01/13/2006 07:39:38.361:43) : arch=i386 syscall=stat64 success=no exit=-13(Permission denied) a0=8afdf68 a1=8aa20c8 a2=ae8ff4 a3=8afdf68 items=1 pid=3926 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=perl exe=/usr/bin/perl type=AVC msg=audit(01/13/2006 07:39:38.361:43) : avc: denied { getattr } for pid=3926 comm=perl name=/ dev=selinuxfs ino=327 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=dir ---- type=PATH msg=audit(01/13/2006 07:39:40.729:44) : item=0 name=/usr/sbin/ntpd flags=follow inode=135413 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/13/2006 07:39:40.729:44) : cwd=/ type=AVC_PATH msg=audit(01/13/2006 07:39:40.729:44) : path=/usr/sbin/ntpd type=SYSCALL msg=audit(01/13/2006 07:39:40.729:44) : arch=i386 syscall=stat64 success=no exit=-13(Permission denied) a0=9c7bf68 a1=9c200c8 a2=ae8ff4 a3=9c7bf68 items=1 pid=4198 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=perl exe=/usr/bin/perl type=AVC msg=audit(01/13/2006 07:39:40.729:44) : avc: denied { getattr } for pid=4198 comm=perl name=ntpd dev=dm-0 ino=135413 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:ntpd_exec_t:s0 tclass=file ---- type=PATH msg=audit(01/13/2006 07:39:41.081:45) : item=0 name=/usr/sbin/sendmail flags=follow,open inode=130890 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/13/2006 07:39:41.081:45) : cwd=/ type=SYSCALL msg=audit(01/13/2006 07:39:41.081:45) : arch=i386 syscall=execve success=no exit=-13(Permission denied) a0=8057d63 a1=87d3604 a2=bfa400c8 a3=87d3604 items=1 pid=4213 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=mail exe=/bin/mail type=AVC msg=audit(01/13/2006 07:39:41.081:45) : avc: denied { read } for pid=4213 comm=mail name=sendmail dev=dm-0 ino=138949 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:sbin_t:s0 tclass=lnk_file -- Tom London From tim at birdsnest.maths.tcd.ie Fri Jan 13 23:35:25 2006 From: tim at birdsnest.maths.tcd.ie (Timothy Murphy) Date: Fri, 13 Jan 2006 23:35:25 +0000 Subject: Stopping SELinux Message-ID: Sorry to be a bore, but how does one stop selinux running? Is it sufficient to set "SELINUX=disabled" in /etc/selinux/config ? [I'm afraid since I started running selinux I've been having problems with my WiFi network - quite likely nothing to do with SELinux, but all the same I'd like to make sure it is not running during diagnostics. I have made the setting above, but still seem to get messages about selinux in /var/log/messages . Is there any process I should kill ?] -- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From ivg2 at cornell.edu Fri Jan 13 23:57:05 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 13 Jan 2006 16:57:05 -0700 Subject: Stopping SELinux In-Reply-To: References: Message-ID: <43C83E51.8080003@cornell.edu> Timothy Murphy wrote: > Sorry to be a bore, > but how does one stop selinux running? > Is it sufficient to set "SELINUX=disabled" > in /etc/selinux/config ? > > [I'm afraid since I started running selinux > I've been having problems with my WiFi network - > quite likely nothing to do with SELinux, > but all the same I'd like to make sure it is not running > during diagnostics. > I have made the setting above, > but still seem to get messages about selinux in /var/log/messages . > Is there any process I should kill ?] > To stop selinux completely, that should be sufficient (I think), or you can pass selinux=0 to the kernel. In either case, you need to reboot the machine. To debug problems with selinux, however, you should run it in permissive mode, which disables enforcement, but keeps selinux running, and logging any errors. Otherwise, any files created while selinux is off will have no security context, and you'll need to relabel afterwards to fix your machine. You can change enforcing status permanently by editing /etc/selinux/config (or with system-config-securitylevel, or by passing enforcing=0 to kernel). You can also use /usr/sbin/setenforce, which changes the current enforcing status, without making it permanent (does not need a reboot). You can use /usr/sbin/getenforce to check if it worked. From ivg2 at cornell.edu Fri Jan 13 23:58:20 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 13 Jan 2006 16:58:20 -0700 Subject: Stopping SELinux In-Reply-To: <43C83E51.8080003@cornell.edu> References: <43C83E51.8080003@cornell.edu> Message-ID: <43C83E9C.1040003@cornell.edu> Ivan Gyurdiev wrote: > Timothy Murphy wrote: >> Sorry to be a bore, >> but how does one stop selinux running? >> Is it sufficient to set "SELINUX=disabled" >> in /etc/selinux/config ? >> >> [I'm afraid since I started running selinux >> I've been having problems with my WiFi network - >> quite likely nothing to do with SELinux, >> but all the same I'd like to make sure it is not running >> during diagnostics. >> I have made the setting above, >> but still seem to get messages about selinux in /var/log/messages . >> Is there any process I should kill ?] >> > To stop selinux completely, that should be sufficient (I think), or > you can pass selinux=0 to the kernel. > In either case, you need to reboot the machine. To debug problems with > selinux, however, you should run it in permissive mode, which disables > enforcement, but keeps selinux running, and logging any errors. > Otherwise, any files created while selinux is off will have no > security context, and you'll need to relabel afterwards to fix your > machine. You can change enforcing status permanently by editing > /etc/selinux/config (or with system-config-securitylevel, or by > passing enforcing=0 to kernel). You can also use /usr/sbin/setenforce, > which changes the current enforcing status, without making it > permanent (does not need a reboot). You can use /usr/sbin/getenforce > to check if it worked. And no, there is no process to kill, since selinux is in the kernel - that's why you have to reboot the machine to turn it off, and pass the proper parameters to the kernel. From symphony at ig.com.br Sat Jan 14 03:25:08 2006 From: symphony at ig.com.br (symphony) Date: Sat, 14 Jan 2006 01:25:08 -0200 Subject: Selinux Audit in FC 4 Message-ID: <20060114_032508_025744.symphony@ig.com.br> Hi, i'm beginner in Selinux and FC4. I read in the FAQ of the site of the fedora that needs to qualify the audit in kernel, somebody I can say me as to make this? Exists some tools that it tests the eficiencia of the SELinux in the FC4? Thanks From selinux at gmail.com Sat Jan 14 17:36:03 2006 From: selinux at gmail.com (Tom London) Date: Sat, 14 Jan 2006 09:36:03 -0800 Subject: rawhide avcs...(hostname, restorecon) Message-ID: <4c4ba1530601140936m6c3b34c9q4fdbfb1aed9949c5@mail.gmail.com> Avcs from today's rawhide (selinux-policy-targeted-2.1.10-1) (enforcing): >From /var/log/messages: Jan 14 09:27:16 localhost kernel: SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts Jan 14 09:27:16 localhost kernel: audit(1137230757.160:2): avc: denied { read write } for pid=400 comm="hostname" name="console" dev=tmpfs ino=560 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file Jan 14 09:27:16 localhost kernel: audit(1137230757.160:3): avc: denied { read write } for pid=400 comm="hostname" name="console" dev=tmpfs ino=560 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file Jan 14 09:27:16 localhost kernel: audit(1137230757.160:4): avc: denied { read write } for pid=400 comm="hostname" name="console" dev=tmpfs ino=560 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file Jan 14 09:27:16 localhost kernel: SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts Jan 14 09:27:16 localhost kernel: audit(1137230758.780:5): avc: denied { write } for pid=413 comm="restorecon" name="[987]" dev=pipefs ino=987 scontext=system_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:restorecon_t:s0 tclass=fifo_file Jan 14 09:27:16 localhost kernel: audit(1137230758.780:6): avc: denied { read } for pid=412 comm="restorecon" name="[987]" dev=pipefs ino=987 scontext=system_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:restorecon_t:s0 tclass=fifo_file Jan 14 09:27:16 localhost kernel: hw_random hardware driver 1.0.0 loaded -- Tom London From maschino at jouy.inra.fr Mon Jan 16 17:35:00 2006 From: maschino at jouy.inra.fr (Emeric Maschino) Date: Mon, 16 Jan 2006 18:35:00 +0100 Subject: Denied { search } mingetty and can't log in In-Reply-To: <1136886574.5079.29.camel@localhost.localdomain> References: <1136886574.5079.29.camel@localhost.localdomain> Message-ID: <1137432900.29976.24.camel@localhost.localdomain> Hi, Just to let you know that this problem > libsemanage.dbase_policydb_list: out of memory > libsemanage.semanage_exec_prog: Child process /usr/sbin/genhomedircon > did not exit cleanly. > libsemanage.semanage_install_sandbox: genhomedircon returned error code > -1. > semodule: Failed! seems to have been corrected in the latest SELinux updates (checkpolicy 1.28-5, policycoreutils 1.29.7-3, libsepol 1.11.9-1, libsetrans 0.1.17-1, selinux-policy-{targeted}-2.1.10-1). Many thanks. However, I'm still getting the AVCs exhibited in this post (https://www.redhat.com/archives/fedora-selinux-list/2006- January/msg00049.html). Cheers, ?meric From stephen.walton at csun.edu Mon Jan 16 19:40:29 2006 From: stephen.walton at csun.edu (Stephen Walton) Date: Mon, 16 Jan 2006 11:40:29 -0800 Subject: amrestore problem, still Message-ID: <43CBF6AD.3020208@csun.edu> Hi, Running FC4 pretty much out of the box. If you look at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168136, you'll see a bug I filed some time ago about conflicts with SELinux and amrecover. The last comment there says "Fixed in selinux-policy-*-1.27.1-2.1" which is true for that specific bug, but one still can't use amrecover because of some problem with the index server amindexd. I've attached the audit log below. The on disk copy of amindexd has context system_u:object_r:amanda_inetd_exec_t. Do I need to file another bug report on bugzilla? type=AVC msg=audit(1137440126.806:65011): avc: denied { read write } for pid=30860 comm="amindexd" name="[39498626]" dev=sockfs ino=39498626 scontext=system_u:system_r:amanda_t tcontext=system_u:system_r:inetd_t tclass=tcp_socket type=SYSCALL msg=audit(1137440126.806:65011): arch=40000003 syscall=11 success=yes exit=0 a0=8a39640 a1=8a39ab8 a2=8a3ee88 a3=bfe6b964 items=2 pid=30860 auid=4294967295 uid=33 gid=6 euid=33 suid=33 fsuid=33 egid=6 sgid=6 fsgid=6 comm="amindexd" exe="/usr/lib/amanda/amindexd" type=AVC_PATH msg=audit(1137440126.806:65011): path="socket:[39498626]" type=CWD msg=audit(1137440126.806:65011): cwd="/" type=PATH msg=audit(1137440126.806:65011): item=0 name="/usr/lib/amanda/amindexd" flags=101 inode=776533 dev=fd:03 mode=0100755 ouid=33 ogid=6 rdev=00:00 type=PATH msg=audit(1137440126.806:65011): item=1 flags=101 inode=89458 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1137440126.862:65012): avc: denied { getattr } for pid=30860 comm="amindexd" laddr=127.0.0.1 lport=10082 faddr=127.0.0.1 fport=521 scontext=system_u:system_r:amanda_t tcontext=system_u:system_r:inetd_t tclass=tcp_socket type=SYSCALL msg=audit(1137440126.862:65012): arch=40000003 syscall=102 success=yes exit=0 a0=7 a1=bf9f4110 a2=aea498 a3=0 items=0 pid=30860 auid=4294967295 uid=33 gid=6 euid=33 suid=33 fsuid=33 egid=6 sgid=6 fsgid=6 comm="amindexd" exe="/usr/lib/amanda/amindexd" type=SOCKETCALL msg=audit(1137440126.862:65012): nargs=3 a0=0 a1=bf9f4254 a2=bf9f4268 From srinivasa at in.ibm.com Tue Jan 17 13:17:14 2006 From: srinivasa at in.ibm.com (srinivasa) Date: Tue, 17 Jan 2006 18:47:14 +0530 Subject: dbus error message Message-ID: <1137503834.4938.19.camel@srinivasa.in.ibm.com> Hi Iam getting selinux dbus error message on my RHEL4 machine This is different from earlier dbus error messages which is there earlier and selinux-policy-targeted-1.17.30-2.117.noarch.rpm(from Daniel walsh) has fixed it. This one looks different from that and it doesn't have "denied send_msg" message which has security class fields and helped in debugging. Error messages looks like this ================================================================= Jan 17 17:02:07 x330b dbus: Can't send to audit system: USER_AVC pid=7704 uid=81 loginuid=0 message=avc: received policyload notice (seqno=16) Jan 17 17:02:07 x330b dbus: Can't send to audit system: USER_AVC pid=7704 uid=81 loginuid=0 message=avc: 0 AV entries and 0/512 buckets used, longest chain length 0 Jan 17 17:02:24 x330b dbus: Can't send to audit system: USER_AVC pid=7704 uid=81 loginuid=0 message=avc: received setenforce notice (enforcing=1) =================================================================== I just wanted to know,why this error message is getting generated and how to fix it out. Is it due to lack of send_msg permission? Looking for reply Srinivasa DS From linux_4ever at yahoo.com Tue Jan 17 13:41:16 2006 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 17 Jan 2006 05:41:16 -0800 (PST) Subject: dbus error message In-Reply-To: <1137503834.4938.19.camel@srinivasa.in.ibm.com> Message-ID: <20060117134116.32601.qmail@web51505.mail.yahoo.com> >I just wanted to know,why this error message is getting generated and >how to fix it out. It would appear that dbus does not have CAP_AUDIT_WRITE permissions - which is why the message takes the form it does. However, the messages are just normal SE Linux policy load messages. To me, the question is do you just get a couple of these or does it fill the logs with it? If you just get a couple, all is well. If its filling your logs, then we should look into it more. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dwalsh at redhat.com Tue Jan 17 15:37:30 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 17 Jan 2006 10:37:30 -0500 Subject: rawhide avcs...(hostname, restorecon) In-Reply-To: <4c4ba1530601140936m6c3b34c9q4fdbfb1aed9949c5@mail.gmail.com> References: <4c4ba1530601140936m6c3b34c9q4fdbfb1aed9949c5@mail.gmail.com> Message-ID: <43CD0F3A.5090208@redhat.com> Tom London wrote: > Avcs from today's rawhide (selinux-policy-targeted-2.1.10-1) (enforcing): > > >From /var/log/messages: > Jan 14 09:27:16 localhost kernel: SELinux: initialized (dev sysfs, > type sysfs), uses genfs_contexts > Jan 14 09:27:16 localhost kernel: audit(1137230757.160:2): avc: > denied { read write } for pid=400 comm="hostname" name="console" > dev=tmpfs ino=560 scontext=system_u:system_r:hostname_t:s0 > tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file > Jan 14 09:27:16 localhost kernel: audit(1137230757.160:3): avc: > denied { read write } for pid=400 comm="hostname" name="console" > dev=tmpfs ino=560 scontext=system_u:system_r:hostname_t:s0 > tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file > Jan 14 09:27:16 localhost kernel: audit(1137230757.160:4): avc: > denied { read write } for pid=400 comm="hostname" name="console" > dev=tmpfs ino=560 scontext=system_u:system_r:hostname_t:s0 > tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file > Jan 14 09:27:16 localhost kernel: SELinux: initialized (dev usbfs, > type usbfs), uses genfs_contexts > Jan 14 09:27:16 localhost kernel: audit(1137230758.780:5): avc: > denied { write } for pid=413 comm="restorecon" name="[987]" > dev=pipefs ino=987 scontext=system_u:system_r:restorecon_t:s0 > tcontext=system_u:system_r:restorecon_t:s0 tclass=fifo_file > Jan 14 09:27:16 localhost kernel: audit(1137230758.780:6): avc: > denied { read } for pid=412 comm="restorecon" name="[987]" > dev=pipefs ino=987 scontext=system_u:system_r:restorecon_t:s0 > tcontext=system_u:system_r:restorecon_t:s0 tclass=fifo_file > Jan 14 09:27:16 localhost kernel: hw_random hardware driver 1.0.0 loaded > > -- > Tom London > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > 2.1.11-1 should fix From ynakam at gwu.edu Tue Jan 17 22:22:51 2006 From: ynakam at gwu.edu (Yuichi Nakamura) Date: Tue, 17 Jan 2006 17:22:51 -0500 Subject: [ANN] SELinux Policy Editor 1.3.1 Message-ID: <20060117172251.22f6d601.ynakam@gwu.edu> Hi. SELinux Policy Editor 1.3.1 has been released. About SELinux Policy Editor, visit http://seedit.sourceforge.net/ (1) Notice This release includes Simplified Policy only. GUI is not included, it will be re-developped. It is development version, may be unstable. And tested only in Fedora Core4. (2) Changes * audit2spdl utility It works like audit2allow, generates simplified policy from log. You do not have to remember detail of simplified policy syntax. * Detailed permission for files support For users who want more security, new permission a(Append),t(seTattr), c(Create), e(Erace),o(Overwrite) can be used. * Documentation Documentation about what permissions are integrated, unsupported by simplified policy is prepared. Verifying security of Simplified Policy has become easier. See http://seedit.sourceforge.net/doc/permission_integrate/ * Generation of above document using XML/Python (3) How to use First get seedit-converter-1.3.1-1.i386.rpm and seedit-policy-1.3.1-FC4.noarch.rpm from http://sourceforge.net/project/showfiles.php?group_id=135756 How to install is the same as 1.2, see http://seedit.sourceforge.net/doc/install/INSTALL.html For detail, see manual at http://seedit.sourceforge.net/doc_devel/simplified_policy_manual/ (4) Plan - XML support to be handled easily by UI tools - New GUI - Review security of simplified policy, prepare document If you have question, comment, suggestion and others, please feel free to send me e-mail(ynakam at gwu.edu). ----- Yuichi Nakamura Japan SELinux Users Group(JSELUG) SELinux Policy Editor: http://seedit.sourceforge.net/ From srinivasa at in.ibm.com Wed Jan 18 06:09:42 2006 From: srinivasa at in.ibm.com (srinivasa) Date: Wed, 18 Jan 2006 11:39:42 +0530 Subject: dbus error message In-Reply-To: <20060117134116.32601.qmail@web51505.mail.yahoo.com> References: <20060117134116.32601.qmail@web51505.mail.yahoo.com> Message-ID: <1137564582.4938.26.camel@srinivasa.in.ibm.com> On Tue, 2006-01-17 at 05:41 -0800, Steve G wrote: > >I just wanted to know,why this error message is getting generated and > >how to fix it out. > Thanks Steve for your reply,but what I feel is,if these messages are due to CAP_AUDIT_WRITE capability problem then,adding this line to policy would have fixed the problem but that was not happening. allow initrc_t self:capability { audit_write audit_control }; > It would appear that dbus does not have CAP_AUDIT_WRITE permissions - which is > why the message takes the form it does. > However, the messages are just normal SE > Linux policy load messages. To me, the question is do you just get a couple of > these or does it fill the logs with it? If you just get a couple, all is well. If > its filling your logs, then we should look into it more. > These meesages sometimes fills log,and appears on execution of setenforce,make load and some selinux command. > -Steve > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > From linux_4ever at yahoo.com Wed Jan 18 14:08:20 2006 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 18 Jan 2006 06:08:20 -0800 (PST) Subject: dbus error message In-Reply-To: <1137564582.4938.26.camel@srinivasa.in.ibm.com> Message-ID: <20060118140820.51904.qmail@web51509.mail.yahoo.com> >I feel is,if these messages are due to CAP_AUDIT_WRITE capability problem >then,adding this line to policy would have fixed the problem but that was not >happening. > >allow initrc_t self:capability { audit_write audit_control }; There are 2 ways that the syscall can fail, MAC checks and DAC checks. The above line may help MAC checks, but does nothing for the DAC check. I have a patch in rawhide that is being tested so that when dbus changes from root to the dbus user, it retains that capability. When I'm satisfied that I haven't introduced a new bug with that patch, I'll port it to dbus in RHEL4 - maybe U4. >> does it fill the logs with it? If you just get a couple, all is well. > >These meesages sometimes fills log,and appears on execution of >setenforce,make load and some selinux command. There was an updated targeted policy released after U2 that should alleviate any MAC check problems. The DAC check problem shouldn't fill your logs. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jbrindle at tresys.com Wed Jan 18 14:42:37 2006 From: jbrindle at tresys.com (Joshua Brindle) Date: Wed, 18 Jan 2006 09:42:37 -0500 Subject: SELinux Symposium WiPs, BoFs, and Case Studies Reminder Message-ID: <43CE53DD.7070204@tresys.com> This is a reminder to submit WiPs, BoFs, and Case Studies for the 2006 SELinux symposium. If you have interesting information about SELinux that is not already part of the agenda, please consider submitting something. The deadline for case studies and WiPs is February 1. The deadline for BoFs is February 15. There is limited space for all three. Accepted presenters will be notified by email and the final schedule will be placed on the website and posted at the conference. SELinux Case Studies Case studies are an opportunity to present lessons-learned and success stories about deployed, SELinux-based enterprise solutions and/or SELinux-based products. There is time for 2-3 case studies with presentations of 20-30 minutes with no formal paper required. Interested parties can submit case studies to chair at selinux-symposium.org. Please include a title, no more than one-page description of the case study, participating organizations, and contact information for the presenters. Work-in-Progress Reports (WiPs) WiPs are an opportunity to present emerging projects and technologies to the community in short presentations. The presentations usually cover works-in-progress, new results, status updates, or timely topics. There is time for 6-8 WiPs with presentations of 10 - 15 minutes with no formal paper required. Speakers should submit the title of the presentation, a one paragraph abstract, and a brief speaker bio to chair at selinux-symposium.org. Birds-of-a-Feather Sessions (BoFs) BoFs are an opportunity to have an informal gathering of community members interested in a particular topic. BoFs often include a brief presentation or demonstration followed by discussion. There is time for 4 BoFs of 45 minutes each. BoFs will be scheduled during the Symposium reception. Interested parties can submit suggestions for BoFs to chair at selinux-symposium.org. Please include a title, brief description of the topic, and contact information for the organizer. From tim at birdsnest.maths.tcd.ie Thu Jan 19 13:32:03 2006 From: tim at birdsnest.maths.tcd.ie (Timothy Murphy) Date: Thu, 19 Jan 2006 13:32:03 +0000 Subject: Stopping SELinux References: <43C83E51.8080003@cornell.edu> <43C83E9C.1040003@cornell.edu> Message-ID: Ivan Gyurdiev wrote: >>> Sorry to be a bore, >>> but how does one stop selinux running? >>> Is it sufficient to set "SELINUX=disabled" >>> in /etc/selinux/config ? > And no, there is no process to kill, since selinux is in the kernel - > that's why you have to reboot the machine to turn it off, and pass the > proper parameters to the kernel. What are the "proper parameters"? -- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From sds at tycho.nsa.gov Thu Jan 19 13:52:52 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 19 Jan 2006 08:52:52 -0500 Subject: Stopping SELinux In-Reply-To: References: <43C83E51.8080003@cornell.edu> <43C83E9C.1040003@cornell.edu> Message-ID: <1137678772.3648.7.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-01-19 at 13:32 +0000, Timothy Murphy wrote: > Ivan Gyurdiev wrote: > > >>> Sorry to be a bore, > >>> but how does one stop selinux running? > >>> Is it sufficient to set "SELINUX=disabled" > >>> in /etc/selinux/config ? > > > And no, there is no process to kill, since selinux is in the kernel - > > that's why you have to reboot the machine to turn it off, and pass the > > proper parameters to the kernel. > > What are the "proper parameters"? Setting SELINUX=disabled in /etc/selinux/config is sufficient, but you can alternatively add selinux=0 to your kernel boot parameters to disable SELinux. They end up having the same net effect; it is just a matter of when it gets disabled (immediately via selinux=0 or later by /sbin/init via /etc/selinux/config). -- Stephen Smalley National Security Agency From tim at birdsnest.maths.tcd.ie Thu Jan 19 14:00:45 2006 From: tim at birdsnest.maths.tcd.ie (Timothy Murphy) Date: Thu, 19 Jan 2006 14:00:45 +0000 Subject: Stopping SELinux References: <43C83E51.8080003@cornell.edu> <43C83E9C.1040003@cornell.edu> <1137678772.3648.7.camel@moss-spartans.epoch.ncsc.mil> Message-ID: Stephen Smalley wrote: > On Thu, 2006-01-19 at 13:32 +0000, Timothy Murphy wrote: >> > And no, there is no process to kill, since selinux is in the kernel - >> > that's why you have to reboot the machine to turn it off, and pass the >> > proper parameters to the kernel. >> >> What are the "proper parameters"? > > Setting SELINUX=disabled in /etc/selinux/config is sufficient, but you > can alternatively add selinux=0 to your kernel boot parameters to > disable SELinux. They end up having the same net effect; it is just a > matter of when it gets disabled (immediately via selinux=0 or later > by /sbin/init via /etc/selinux/config). OK, thanks. I did realize this, but was being a little snide as the advice to "pass the proper parameters to the kernel" struck me as not very helpful - I didn't notice it was the same poster who had previously mentioned "selinux=0". Incidentally, I do find kernel parameters fairly confusing. Is there a list anywhere of the possibilites (is the number finite?) anywhere? There used to be a very useful list in the RedHat manual. -- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From sds at tycho.nsa.gov Thu Jan 19 14:18:17 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 19 Jan 2006 09:18:17 -0500 Subject: Stopping SELinux In-Reply-To: References: <43C83E51.8080003@cornell.edu> <43C83E9C.1040003@cornell.edu> <1137678772.3648.7.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1137680297.3648.17.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-01-19 at 14:00 +0000, Timothy Murphy wrote: > Incidentally, I do find kernel parameters fairly confusing. > Is there a list anywhere of the possibilites (is the number finite?) > anywhere? > There used to be a very useful list in the RedHat manual. The /etc/selinux/config settings were actually introduced on the advice of Red Hat because kernel parameters are both user-unfriendly and painful to change on some platforms. With regard to kernel parameters, there is now a list in the kernel's Documentation tree (Documentation/kernel-parameters.txt) http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;h=1cbcf65b764b47137b0db013654e55f224c3c32c;f=Documentation/kernel-parameters.txt The SELinux-related ones are marked with [SELINUX] there. -- Stephen Smalley National Security Agency From jmorris at namei.org Thu Jan 19 15:56:53 2006 From: jmorris at namei.org (James Morris) Date: Thu, 19 Jan 2006 10:56:53 -0500 (EST) Subject: MCS article Message-ID: If anyone wants to play with MCS, have a look at this article I just posted: "Getting Started with Multi-Category Security (MCS)" http://james-morris.livejournal.com/8228.html Feedback, suggestions etc. welcome. - James -- James Morris From dwalsh at redhat.com Thu Jan 19 16:33:01 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 19 Jan 2006 11:33:01 -0500 Subject: amrestore problem, still In-Reply-To: <43CBF6AD.3020208@csun.edu> References: <43CBF6AD.3020208@csun.edu> Message-ID: <43CFBF3D.9030003@redhat.com> Stephen Walton wrote: > Hi, > > Running FC4 pretty much out of the box. If you look at > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168136, you'll > see a bug I filed some time ago about conflicts with SELinux and > amrecover. The last comment there says "Fixed in > selinux-policy-*-1.27.1-2.1" which is true for that specific bug, but > one still can't use amrecover because of some problem with the index > server amindexd. I've attached the audit log below. The on disk copy > of amindexd has context system_u:object_r:amanda_inetd_exec_t. > > Do I need to file another bug report on bugzilla? > > type=AVC msg=audit(1137440126.806:65011): avc: denied { read write } > for pid=30860 comm="amindexd" name="[39498626]" dev=sockfs > ino=39498626 scontext=system_u:system_r:amanda_t > tcontext=system_u:system_r:inetd_t tclass=tcp_socket > type=SYSCALL msg=audit(1137440126.806:65011): arch=40000003 syscall=11 > success=yes exit=0 a0=8a39640 a1=8a39ab8 a2=8a3ee88 a3=bfe6b964 > items=2 pid=30860 auid=4294967295 uid=33 gid=6 euid=33 suid=33 > fsuid=33 egid=6 sgid=6 fsgid=6 comm="amindexd" > exe="/usr/lib/amanda/amindexd" > type=AVC_PATH msg=audit(1137440126.806:65011): path="socket:[39498626]" > type=CWD msg=audit(1137440126.806:65011): cwd="/" > type=PATH msg=audit(1137440126.806:65011): item=0 > name="/usr/lib/amanda/amindexd" flags=101 inode=776533 dev=fd:03 > mode=0100755 ouid=33 ogid=6 rdev=00:00 > type=PATH msg=audit(1137440126.806:65011): item=1 flags=101 > inode=89458 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 > type=AVC msg=audit(1137440126.862:65012): avc: denied { getattr } > for pid=30860 comm="amindexd" laddr=127.0.0.1 lport=10082 > faddr=127.0.0.1 fport=521 scontext=system_u:system_r:amanda_t > tcontext=system_u:system_r:inetd_t tclass=tcp_socket > type=SYSCALL msg=audit(1137440126.862:65012): arch=40000003 > syscall=102 success=yes exit=0 a0=7 a1=bf9f4110 a2=aea498 a3=0 items=0 > pid=30860 auid=4294967295 uid=33 gid=6 euid=33 suid=33 fsuid=33 egid=6 > sgid=6 fsgid=6 comm="amindexd" exe="/usr/lib/amanda/amindexd" > type=SOCKETCALL msg=audit(1137440126.862:65012): nargs=3 a0=0 > a1=bf9f4254 a2=bf9f4268 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list These error messages do not make any sense. These indicate you have a port labeled inetd_t? I think there was something wrong with your machine? Do you still see these errors after a reboot? Dan From nutello at sweetness.com Thu Jan 19 17:18:33 2006 From: nutello at sweetness.com (Rudi Chiarito) Date: Thu, 19 Jan 2006 18:18:33 +0100 Subject: MCS article In-Reply-To: References: Message-ID: <20060119171833.GC6479@plain.rackshack.net> On Thu, Jan 19, 2006 at 10:56:53AM -0500, James Morris wrote: > "Getting Started with Multi-Category Security (MCS)" > http://james-morris.livejournal.com/8228.html > Feedback, suggestions etc. welcome. My burning question would be: is any of that supported by any of the network filesystems yet? If not, who might get there first? I know this is a problem with SELinux in general, not just MCS. I remember seeing NFSv3 patches, but I guess they have been abandoned and future work would have to happen on NFSv4. MCS makes SELinux more palatable to a wider audience, but that also attracts people with varying requirements and network filesystems are becoming harder to avoid. Thanks for the great work. -- Rudi From jmorris at namei.org Thu Jan 19 19:48:24 2006 From: jmorris at namei.org (James Morris) Date: Thu, 19 Jan 2006 14:48:24 -0500 (EST) Subject: MCS article In-Reply-To: <20060119171833.GC6479@plain.rackshack.net> References: <20060119171833.GC6479@plain.rackshack.net> Message-ID: On Thu, 19 Jan 2006, Rudi Chiarito wrote: > On Thu, Jan 19, 2006 at 10:56:53AM -0500, James Morris wrote: > > "Getting Started with Multi-Category Security (MCS)" > > http://james-morris.livejournal.com/8228.html > > Feedback, suggestions etc. welcome. > > My burning question would be: is any of that supported by any of the > network filesystems yet? If not, who might get there first? NFS support is some way off. For NFSv4, the protocol needs to be modified to include support for Linux/BSD xattrs, as the named attributes in the spec are designed for Solaris xattrs, which are really subfiles. I'm not sure if the old NFSv3 code from the NSA would be acceptable upstream as it's non-standard, although I'm not sure if anyone has really looked into this issue with upstream folk. Adding MCS support to Samba, however, seems potentially simpler, in that the server runs in userspace, and that the protocol may not need to be modified (for just MCS). - James -- James Morris From jwcart2 at epoch.ncsc.mil Fri Jan 20 13:53:56 2006 From: jwcart2 at epoch.ncsc.mil (James Carter) Date: Fri, 20 Jan 2006 08:53:56 -0500 Subject: MCS article In-Reply-To: References: <20060119171833.GC6479@plain.rackshack.net> Message-ID: <1137765236.1179.36.camel@moss-lions.epoch.ncsc.mil> The SELinux NFS code was never submitted upstream since NFSv4 was coming and it wouldn't make sense to have v3 support SELinux, but not v4. It also seemed like it would be easier to get upstream support with NFSv4 using named attributes to pass file contexts and a SELinux specific rpcsec_gss security flavor to pass the client process's context then with NFSv3 using non-standard extensions. The NFSv4 named attributes are still not implemented on Linux although there has been talk about them over the last month on the NFSv4 mailing list. Support is just being added to allow specifying a security flavor for each export. If you are interested, here is the talk I gave at last year's SELinux Symposium: http://www.selinux-symposium.org/2005/presentations/session2/2-4-carter.pdf The NFSv3 code (for 2.6.11) is still available in the historical section of the download page: http://www.nsa.gov/selinux/code/download1.cfm Jim On Thu, 2006-01-19 at 14:48 -0500, James Morris wrote: > On Thu, 19 Jan 2006, Rudi Chiarito wrote: > > > On Thu, Jan 19, 2006 at 10:56:53AM -0500, James Morris wrote: > > > "Getting Started with Multi-Category Security (MCS)" > > > http://james-morris.livejournal.com/8228.html > > > Feedback, suggestions etc. welcome. > > > > My burning question would be: is any of that supported by any of the > > network filesystems yet? If not, who might get there first? > > NFS support is some way off. For NFSv4, the protocol needs to be modified > to include support for Linux/BSD xattrs, as the named attributes in the > spec are designed for Solaris xattrs, which are really subfiles. > > I'm not sure if the old NFSv3 code from the NSA would be acceptable > upstream as it's non-standard, although I'm not sure if anyone has really > looked into this issue with upstream folk. > > Adding MCS support to Samba, however, seems potentially simpler, in that > the server runs in userspace, and that the protocol may not need to be > modified (for just MCS). > > > - James -- James Carter National Security Agency From jmorris at namei.org Fri Jan 20 14:37:37 2006 From: jmorris at namei.org (James Morris) Date: Fri, 20 Jan 2006 09:37:37 -0500 (EST) Subject: MCS article In-Reply-To: <1137765236.1179.36.camel@moss-lions.epoch.ncsc.mil> References: <20060119171833.GC6479@plain.rackshack.net> <1137765236.1179.36.camel@moss-lions.epoch.ncsc.mil> Message-ID: On Fri, 20 Jan 2006, James Carter wrote: > The NFSv4 named attributes are still not implemented on Linux although > there has been talk about them over the last month on the NFSv4 mailing > list. Support is just being added to allow specifying a security flavor > for each export. It's my understanding that these named attributes are not compatible with Linux/BSD extended attributes, as they're based on Solaris ones, which are actually subfiles. - James -- James Morris From sds at tycho.nsa.gov Fri Jan 20 15:32:30 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 20 Jan 2006 10:32:30 -0500 Subject: MCS article In-Reply-To: References: <20060119171833.GC6479@plain.rackshack.net> <1137765236.1179.36.camel@moss-lions.epoch.ncsc.mil> Message-ID: <1137771150.3648.156.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-01-20 at 09:37 -0500, James Morris wrote: > On Fri, 20 Jan 2006, James Carter wrote: > > > The NFSv4 named attributes are still not implemented on Linux although > > there has been talk about them over the last month on the NFSv4 mailing > > list. Support is just being added to allow specifying a security flavor > > for each export. > > It's my understanding that these named attributes are not compatible with > Linux/BSD extended attributes, as they're based on Solaris ones, which are > actually subfiles. When I mentioned that the NFSv4 named attributes might not be suitable for our purposes to the Trusted Solaris folks, they said that they should be and that any lack there is one of the Linux implementation, not the protocol definition or its intended implementation. -- Stephen Smalley National Security Agency From gene at czarc.net Fri Jan 20 15:26:28 2006 From: gene at czarc.net (Gene Czarcinski) Date: Fri, 20 Jan 2006 10:26:28 -0500 Subject: selinux patch breaks sudo NOEXEC capability Message-ID: <200601201026.28293.gene@czarc.net> This problem has been reported as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178429 against fc5test1/development although it exists in FC4 also (the sudo NOEXEC capability was not available in FC3). In sudo 1.6.8p8 and later (maybe a bit earlier too) adds a NOEXEC option. The NOEXEC option is an important security feature since it suppresses a user's ability to "shell out" of a program such as vi to get general root access. When NOEXEC is working, you can use "sudo vi xxx" to edit file xxx but you cannot shell out (e.g., ":!bash") from vi. If the selinux patch to the sudo package is applied, then you get the message: /usr/sbin/sesh: Error execing /bin/vi: Permission denied and you cannot run vi (or anything) under sudo (when "Defaults noexec" is specified in the /etc/sudoers file). A very quick look at the code says that this will not be easy to fix since sudo implements NOEXEC by dummying out the "exec" functions for the program run by sudo. With the selinux patch applied, sudo invokes /usr/sbin/sesh before invoking your program and sesh is using the dummied-out exec function. Gene From sds at tycho.nsa.gov Fri Jan 20 15:39:23 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 20 Jan 2006 10:39:23 -0500 Subject: selinux patch breaks sudo NOEXEC capability In-Reply-To: <200601201026.28293.gene@czarc.net> References: <200601201026.28293.gene@czarc.net> Message-ID: <1137771563.3648.162.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-01-20 at 10:26 -0500, Gene Czarcinski wrote: > This problem has been reported as > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178429 against > fc5test1/development although it exists in FC4 also (the sudo NOEXEC > capability was not available in FC3). > > In sudo 1.6.8p8 and later (maybe a bit earlier too) adds a NOEXEC option. The > NOEXEC option is an important security feature since it suppresses a user's > ability to "shell out" of a program such as vi to get general root access. > When NOEXEC is working, you can use "sudo vi xxx" to edit file xxx but you > cannot shell out (e.g., ":!bash") from vi. > > If the selinux patch to the sudo package is applied, then you get the message: > > /usr/sbin/sesh: Error execing /bin/vi: Permission denied > > and you cannot run vi (or anything) under sudo (when "Defaults noexec" is > specified in the /etc/sudoers file). > > A very quick look at the code says that this will not be easy to fix since > sudo implements NOEXEC by dummying out the "exec" functions for the program > run by sudo. With the selinux patch applied, sudo invokes /usr/sbin/sesh > before invoking your program and sesh is using the dummied-out exec function. Per other discussions on separating role changes from Unix user identity changes on selinux list and redhat-lspp list, I think that the sudo and usermode selinux patches should just be reverted altogether (except possibly for permission checking code in userhelper for its obscure passwd manipulation interfaces). This would be consistent with the removal of pam_selinux from su's pam configuration, and bring us back to the original SELinux model prior to Fedora integration. seusers can then be used to authorize Unix users for SELinux user identities aka role sets. -- Stephen Smalley National Security Agency From jwcart2 at epoch.ncsc.mil Fri Jan 20 15:38:32 2006 From: jwcart2 at epoch.ncsc.mil (James Carter) Date: Fri, 20 Jan 2006 10:38:32 -0500 Subject: MCS article In-Reply-To: References: <20060119171833.GC6479@plain.rackshack.net> <1137765236.1179.36.camel@moss-lions.epoch.ncsc.mil> Message-ID: <1137771512.1179.63.camel@moss-lions.epoch.ncsc.mil> There was a question last week on the NFSv4 mailing list about support for other ACL models and there seemed to be interest in the idea. It just doesn't seem to be a big priority right now. On Fri, 2006-01-20 at 09:37 -0500, James Morris wrote: > On Fri, 20 Jan 2006, James Carter wrote: > > > The NFSv4 named attributes are still not implemented on Linux although > > there has been talk about them over the last month on the NFSv4 mailing > > list. Support is just being added to allow specifying a security flavor > > for each export. > > It's my understanding that these named attributes are not compatible with > Linux/BSD extended attributes, as they're based on Solaris ones, which are > actually subfiles. > > > - James -- James Carter National Security Agency From jmorris at namei.org Fri Jan 20 16:24:20 2006 From: jmorris at namei.org (James Morris) Date: Fri, 20 Jan 2006 11:24:20 -0500 (EST) Subject: MCS article In-Reply-To: <1137771150.3648.156.camel@moss-spartans.epoch.ncsc.mil> References: <20060119171833.GC6479@plain.rackshack.net> <1137765236.1179.36.camel@moss-lions.epoch.ncsc.mil> <1137771150.3648.156.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Fri, 20 Jan 2006, Stephen Smalley wrote: > When I mentioned that the NFSv4 named attributes might not be suitable > for our purposes to the Trusted Solaris folks, they said that they > should be and that any lack there is one of the Linux implementation, > not the protocol definition or its intended implementation. This thread contains some discussion on the issue: http://www1.ietf.org/mail-archive/web/nfsv4/current/msg02336.html IIRC, the consensus on the issue is to look at adding new OPs for Linux/BSD extended attributes. - James -- James Morris From dragoran at feuerpokemon.de Sat Jan 21 07:59:38 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 21 Jan 2006 08:59:38 +0100 Subject: invalid context root:sysadm_r:initrc_t? Message-ID: <43D1E9EA.9000402@feuerpokemon.de> hello I found this errors in dmesg on a FC4 system using selinux-policy-targeted-1.27.1-2.16: audit(1137825680.353:2): security_compute_sid: invalid context root:sysadm_r:initrc_t for scontext=root:sysadm_r:unconfined_t tcontext=system_u:object_r:initrc_exec_t tclass=process audit(1137825680.617:3): security_compute_sid: invalid context root:sysadm_r:initrc_t for scontext=root:sysadm_r:unconfined_t tcontext=system_u:object_r:initrc_exec_t tclass=process what are this errors? what does invalid context means? From slaspina at 3gbyte.com.ar Mon Jan 23 14:39:08 2006 From: slaspina at 3gbyte.com.ar (=?iso-8859-1?Q?Sebasti=E1n_A._La_Spina?=) Date: Mon, 23 Jan 2006 11:39:08 -0300 Subject: AVC funny msgs! Message-ID: <00b101c6202a$c4d33890$0e01a8c0@Pc05> This is an important avc? Im currently running my SE on permisive mode, im not very sure to run it on enforcing . :( audit(1138026282.862:2): avc: denied { compute_user } for pid=2166 comm="crond" scontext=system_u:system_r:crond_t tcontext=system_u:object_r:security_t tclass=security audit(1138026302.050:4): avc: denied { compute_user } for pid=2533 comm="gdm-binary" scontext=system_u:system_r:unconfined_t tcontext=system_u:object_r:security_t tclass=security audit(1138026456.531:6): avc: denied { compute_relabel } for pid=2702 comm="sshd" scontext=system_u:system_r:unconfined_t tcontext=system_u:object_r:security_t tclass=security Sorry for my litle English... Good luck for all of yours! Sebasti?n From selinux at gmail.com Mon Jan 23 15:11:49 2006 From: selinux at gmail.com (Tom London) Date: Mon, 23 Jan 2006 07:11:49 -0800 Subject: Latest rawhide: boot issue with avahi/hald/... ? Message-ID: <4c4ba1530601230711q4dfb623bi1c6a0022393a2662@mail.gmail.com> Running latest rawhide, targeted/permissive: (only --excude=totem\*) Get the following from audit.log: allow NetworkManager_t initrc_t:unix_stream_socket { acquire_svc connectto }; allow avahi_t initrc_t:unix_stream_socket connectto; allow cupsd_config_t initrc_t:unix_stream_socket { acquire_svc connectto send_msg }; allow dhcpc_t initrc_t:unix_stream_socket { acquire_svc connectto }; allow hald_t initrc_t:unix_stream_socket { acquire_svc connectto }; Seems to be problems accessing /var/run/dbus/system_bus_socket: avc's imply file is initrc_t, but ls -lZ yields: srwxrwxrwx root root system_u:object_r:system_dbusd_var_run_t system_bus_socket 'messagebus' service did move earlier in startup sequence over the weekend, but didn't seem to affect this. Here are a few complete entries from audit.log type=PATH msg=audit(01/23/2006 06:58:02.423:10) : item=0 flags=follow inode=2142247 dev=fd:00 mode=socket,777 ouid=root ogid=root rdev=00:00 type=SOCKETCALL msg=audit(01/23/2006 06:58:02.423:10) : nargs=3 a0=c a1=bf80d3aa a2=21 type=SOCKADDR msg=audit(01/23/2006 06:58:02.423:10) : saddr=local /var/run/dbus/system_bus_socket type=AVC_PATH msg=audit(01/23/2006 06:58:02.423:10) : path=/var/run/dbus/system_bus_socket type=SYSCALL msg=audit(01/23/2006 06:58:02.423:10) : arch=i386 syscall=socketcall(connect) success=yes exit=0 a0=3 a1=bf80d370 a2=4d55d4 a3=1f items=1 pid=2646 auid=unknown(4294967295) uid=avahi gid=avahi euid=avahi suid=avahi fsuid=avahi egid=avahi sgid=avahi fsgid=avahi comm=avahi-daemon exe=/usr/sbin/avahi-daemon type=AVC msg=audit(01/23/2006 06:58:02.423:10) : avc: denied { connectto } for pid=2646 comm=avahi-daemon name=system_bus_socket scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket ---- type=PATH msg=audit(01/23/2006 06:58:02.879:15) : item=0 flags=follow inode=2142247 dev=fd:00 mode=socket,777 ouid=root ogid=root rdev=00:00 type=SOCKETCALL msg=audit(01/23/2006 06:58:02.879:15) : nargs=3 a0=3 a1=bfbe580a a2=21 type=SOCKADDR msg=audit(01/23/2006 06:58:02.879:15) : saddr=local /var/run/dbus/system_bus_socket type=AVC_PATH msg=audit(01/23/2006 06:58:02.879:15) : path=/var/run/dbus/system_bus_socket type=SYSCALL msg=audit(01/23/2006 06:58:02.879:15) : arch=i386 syscall=socketcall(connect) success=yes exit=0 a0=3 a1=bfbe57d0 a2=2835d4 a3=1f items=1 pid=2658 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=cups-config-dae exe=/usr/bin/cups-config-daemon type=AVC msg=audit(01/23/2006 06:58:02.879:15) : avc: denied { connectto } for pid=2658 comm=cups-config-dae name=system_bus_socket scontext=system_u:system_r:cupsd_config_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket ---- tom -- Tom London From rdieter at math.unl.edu Mon Jan 23 15:06:35 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 23 Jan 2006 09:06:35 -0600 Subject: su, context(selinux?) 2nd prompt References: Message-ID: Maciej ?enczykowski wrote: > Weird, I'm not seeing this... Are using an selinux-enabled CentOS 4.2 (or RHEL4U2) box? -- Rex > On Mon, 23 Jan 2006, Rex Dieter wrote: > >> With a recent update of CentOS4, su's behavior has changed, in that after >> prompting for password, also prompts for (selinux?) context. I'm seeing >> something like: >> $ su >> Password: >> Your default context is root:system_r:unconfined_t. >> >> Do you want to choose a different one? [n] >> >> >> kde's kdesu barfs on this second prompt. Any way to disable this second >> prompt? >> >> -- Rex From dwalsh at redhat.com Mon Jan 23 15:46:41 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 23 Jan 2006 10:46:41 -0500 Subject: Latest rawhide: boot issue with avahi/hald/... ? In-Reply-To: <4c4ba1530601230711q4dfb623bi1c6a0022393a2662@mail.gmail.com> References: <4c4ba1530601230711q4dfb623bi1c6a0022393a2662@mail.gmail.com> Message-ID: <43D4FA61.9060101@redhat.com> Tom London wrote: > Running latest rawhide, targeted/permissive: (only --excude=totem\*) > > Get the following from audit.log: > allow NetworkManager_t initrc_t:unix_stream_socket { acquire_svc connectto }; > allow avahi_t initrc_t:unix_stream_socket connectto; > allow cupsd_config_t initrc_t:unix_stream_socket { acquire_svc > connectto send_msg }; > allow dhcpc_t initrc_t:unix_stream_socket { acquire_svc connectto }; > allow hald_t initrc_t:unix_stream_socket { acquire_svc connectto }; > > Seems to be problems accessing /var/run/dbus/system_bus_socket: avc's > imply file is initrc_t, but ls -lZ yields: > srwxrwxrwx root root system_u:object_r:system_dbusd_var_run_t > system_bus_socket > > 'messagebus' service did move earlier in startup sequence over the > weekend, but didn't seem to affect this. > What security context is the dbus-daemon running under? > Here are a few complete entries from audit.log > type=PATH msg=audit(01/23/2006 06:58:02.423:10) : item=0 flags=follow > inode=2142247 dev=fd:00 mode=socket,777 ouid=root ogid=root rdev=00:00 > type=SOCKETCALL msg=audit(01/23/2006 06:58:02.423:10) : nargs=3 a0=c > a1=bf80d3aa a2=21 > type=SOCKADDR msg=audit(01/23/2006 06:58:02.423:10) : saddr=local > /var/run/dbus/system_bus_socket > type=AVC_PATH msg=audit(01/23/2006 06:58:02.423:10) : > path=/var/run/dbus/system_bus_socket > type=SYSCALL msg=audit(01/23/2006 06:58:02.423:10) : arch=i386 > syscall=socketcall(connect) success=yes exit=0 a0=3 a1=bf80d370 > a2=4d55d4 a3=1f items=1 pid=2646 auid=unknown(4294967295) uid=avahi > gid=avahi euid=avahi suid=avahi fsuid=avahi egid=avahi sgid=avahi > fsgid=avahi comm=avahi-daemon exe=/usr/sbin/avahi-daemon > type=AVC msg=audit(01/23/2006 06:58:02.423:10) : avc: denied { > connectto } for pid=2646 comm=avahi-daemon name=system_bus_socket > scontext=system_u:system_r:avahi_t:s0 > tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket > ---- > type=PATH msg=audit(01/23/2006 06:58:02.879:15) : item=0 flags=follow > inode=2142247 dev=fd:00 mode=socket,777 ouid=root ogid=root rdev=00:00 > type=SOCKETCALL msg=audit(01/23/2006 06:58:02.879:15) : nargs=3 a0=3 > a1=bfbe580a a2=21 > type=SOCKADDR msg=audit(01/23/2006 06:58:02.879:15) : saddr=local > /var/run/dbus/system_bus_socket > type=AVC_PATH msg=audit(01/23/2006 06:58:02.879:15) : > path=/var/run/dbus/system_bus_socket > type=SYSCALL msg=audit(01/23/2006 06:58:02.879:15) : arch=i386 > syscall=socketcall(connect) success=yes exit=0 a0=3 a1=bfbe57d0 > a2=2835d4 a3=1f items=1 pid=2658 auid=unknown(4294967295) uid=root > gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root > comm=cups-config-dae exe=/usr/bin/cups-config-daemon > type=AVC msg=audit(01/23/2006 06:58:02.879:15) : avc: denied { > connectto } for pid=2658 comm=cups-config-dae name=system_bus_socket > scontext=system_u:system_r:cupsd_config_t:s0 > tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket > ---- > > tom > -- > Tom London > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From dwalsh at redhat.com Mon Jan 23 15:47:59 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 23 Jan 2006 10:47:59 -0500 Subject: su, context(selinux?) 2nd prompt In-Reply-To: References: Message-ID: <43D4FAAF.6020108@redhat.com> Rex Dieter wrote: > Maciej ?enczykowski wrote: > > >> Weird, I'm not seeing this... >> > > Are using an selinux-enabled CentOS 4.2 (or RHEL4U2) box? > > -- Rex > > Remove multiple from the pam file. >> On Mon, 23 Jan 2006, Rex Dieter wrote: >> >> >>> With a recent update of CentOS4, su's behavior has changed, in that after >>> prompting for password, also prompts for (selinux?) context. I'm seeing >>> something like: >>> $ su >>> Password: >>> Your default context is root:system_r:unconfined_t. >>> >>> Do you want to choose a different one? [n] >>> >>> >>> kde's kdesu barfs on this second prompt. Any way to disable this second >>> prompt? >>> >>> -- Rex >>> > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From selinux at gmail.com Mon Jan 23 15:49:25 2006 From: selinux at gmail.com (Tom London) Date: Mon, 23 Jan 2006 07:49:25 -0800 Subject: Latest rawhide: boot issue with avahi/hald/... ? In-Reply-To: <43D4FA61.9060101@redhat.com> References: <4c4ba1530601230711q4dfb623bi1c6a0022393a2662@mail.gmail.com> <43D4FA61.9060101@redhat.com> Message-ID: <4c4ba1530601230749j4e68a0d0q98e9c01fe2e5e9d3@mail.gmail.com> [root at tlondon ~]# ps agxZ | grep dbus system_u:system_r:initrc_t 2331 ? Ssl 0:01 dbus-daemon --system user_u:system_r:unconfined_t 2971 ? Ss 0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /etc/X11/xinit/Xclients user_u:system_r:unconfined_t 2974 ? S 0:00 /usr/bin/dbus-launch --exit-with-session /etc/X11/xinit/Xclients user_u:system_r:unconfined_t 2975 ? Ssl 0:00 dbus-daemon --fork --print-pid 8 --print-address 6 --session system_u:system_r:dhcpc_t 4489 ? S 0:00 /sbin/dhclient -1 -lf /var/lib/dhclient/dhclient-eth0.leases -cf /etc/dhclient-eth0.conf -pf /var/run/dhclient-eth0.pid -q -e dhc_dbus=31 -x -d eth0 user_u:system_r:unconfined_t:SystemLow-SystemHigh 4583 pts/1 S+ 0:00 grep dbus[root at tlondon ~]# tom -- Tom London From dwalsh at redhat.com Mon Jan 23 15:51:20 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 23 Jan 2006 10:51:20 -0500 Subject: Latest rawhide: boot issue with avahi/hald/... ? In-Reply-To: <4c4ba1530601230749j4e68a0d0q98e9c01fe2e5e9d3@mail.gmail.com> References: <4c4ba1530601230711q4dfb623bi1c6a0022393a2662@mail.gmail.com> <43D4FA61.9060101@redhat.com> <4c4ba1530601230749j4e68a0d0q98e9c01fe2e5e9d3@mail.gmail.com> Message-ID: <43D4FB78.3000003@redhat.com> Tom London wrote: > [root at tlondon ~]# ps agxZ | grep dbus > system_u:system_r:initrc_t 2331 ? Ssl 0:01 dbus-daemon --system > user_u:system_r:unconfined_t 2971 ? Ss 0:00 > /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session > /etc/X11/xinit/Xclients > user_u:system_r:unconfined_t 2974 ? S 0:00 > /usr/bin/dbus-launch --exit-with-session /etc/X11/xinit/Xclients > user_u:system_r:unconfined_t 2975 ? Ssl 0:00 dbus-daemon > --fork --print-pid 8 --print-address 6 --session > system_u:system_r:dhcpc_t 4489 ? S 0:00 > /sbin/dhclient -1 -lf /var/lib/dhclient/dhclient-eth0.leases -cf > /etc/dhclient-eth0.conf -pf /var/run/dhclient-eth0.pid -q -e > dhc_dbus=31 -x -d eth0 > user_u:system_r:unconfined_t:SystemLow-SystemHigh 4583 pts/1 S+ 0:00 > grep dbus[root at tlondon ~]# > > > tom > -- > Tom London > dbus-daemon moved to /sbin File context needs to change. I was told about hal, but not about dbus. From rdieter at math.unl.edu Mon Jan 23 15:50:19 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 23 Jan 2006 09:50:19 -0600 Subject: su, context(selinux?) 2nd prompt References: Message-ID: Maciej ?enczykowski wrote: >>> Weird, I'm not seeing this... >> >> Are using an selinux-enabled CentOS 4.2 (or RHEL4U2) box? > > Yes, an up2date Centos 4.2 box with selinux at the default targeted value. > > However: > $ su - > Password: > # selinuxenabled; echo $? > 0 > # getenforce > Enforcing Interesting. All our boxes that show this behavior were installed originally CentOS 4.1, and upgraded to 4.2. Further, my personal box is only using selinux in permissive mode (too much breakage), but I still see the second prompt. -- Rex From selinux at gmail.com Mon Jan 23 16:04:44 2006 From: selinux at gmail.com (Tom London) Date: Mon, 23 Jan 2006 08:04:44 -0800 Subject: Latest rawhide: boot issue with avahi/hald/... ? In-Reply-To: <43D4FB78.3000003@redhat.com> References: <4c4ba1530601230711q4dfb623bi1c6a0022393a2662@mail.gmail.com> <43D4FA61.9060101@redhat.com> <4c4ba1530601230749j4e68a0d0q98e9c01fe2e5e9d3@mail.gmail.com> <43D4FB78.3000003@redhat.com> Message-ID: <4c4ba1530601230804r52a1f191p5761834aebff792a@mail.gmail.com> I manually did a 'chcon -t system_dbusd_exec_t /bin/dbus_daemon' and rebooted. Problem solved! thanks, tom From rdieter at math.unl.edu Mon Jan 23 15:55:45 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 23 Jan 2006 09:55:45 -0600 Subject: su, context(selinux?) 2nd prompt References: <43D4FAAF.6020108@redhat.com> Message-ID: Daniel J Walsh wrote: >>> On Mon, 23 Jan 2006, Rex Dieter wrote: >>> >>> >>>> With a recent update of CentOS4, su's behavior has changed, in that >>>> after >>>> prompting for password, also prompts for (selinux?) context. I'm >>>> seeing something like: >>>> $ su >>>> Password: >>>> Your default context is root:system_r:unconfined_t. >>>> >>>> Do you want to choose a different one? [n] >>>> >>>> >>>> kde's kdesu barfs on this second prompt. Any way to disable this >>>> second prompt? > Remove multiple from the pam file. editing /etc/pam.d/su, changing session required /lib/security/$ISA/pam_selinux.so open multiple to session required /lib/security/$ISA/pam_selinux.so open Did the trick, thanks Dan! # rpm -q -f /etc/pam.d/su coreutils-5.2.1-31.2 A bug in coreutils-5.2.1-31.2 then? -- Rex From dravet at hotmail.com Tue Jan 24 13:36:54 2006 From: dravet at hotmail.com (Jason Dravet) Date: Tue, 24 Jan 2006 07:36:54 -0600 Subject: new avcs Message-ID: After todays rawhide updates avahi and hal no longer start. Here are the messages in the audit.log. I am running selinux-policy-targeted-2.2.2-1 in enforcing mode. The other software is avahi-0.6.4-4 and hal-0.5.6-2. Thanks, Jason ---- time->Tue Jan 24 07:19:01 2006 type=PATH msg=audit(1138108741.041:9): item=0 name="/etc/blkid.tab" flags=401 inode=2098656 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 type=CWD msg=audit(1138108741.041:9): cwd="/" type=SYSCALL msg=audit(1138108741.041:9): arch=40000003 syscall=33 success=no exit=-13 a0=9676f08 a1=2 a2=98a164 a3=805cdc0 items=1 pid=1966 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="mount" exe="/bin/mount" type=AVC msg=audit(1138108741.041:9): avc: denied { write } for pid=1966 comm="mount" name="blkid.tab" dev=dm-0 ino=2098656 scontext=system_u:system_r:mount_t:s0 tcontext=root:object_r:etc_t:s0 tclass=file ---- time->Tue Jan 24 07:19:05 2006 type=PATH msg=audit(1138108745.294:10): item=0 flags=1 inode=1212726 dev=fd:00 mode=0140777 ouid=0 ogid=0 rdev=00:00 type=SOCKETCALL msg=audit(1138108745.294:10): nargs=3 a0=c a1=bf9e107a a2=21 type=SOCKADDR msg=audit(1138108745.294:10): saddr=01002F7661722F72756E2F646275732F73797374656D5F6275735F736F636B6574 type=AVC_PATH msg=audit(1138108745.294:10): path="/var/run/dbus/system_bus_socket" type=SYSCALL msg=audit(1138108745.294:10): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bf9e1040 a2=f555d4 a3=1f items=1 pid=2096 auid=4294967295 uid=70 gid=70 euid=70 suid=70 fsuid=70 egid=70 sgid=70 fsgid=70 comm="avahi-daemon" exe="/usr/sbin/avahi-daemon" type=AVC msg=audit(1138108745.294:10): avc: denied { connectto } for pid=2096 comm="avahi-daemon" name="system_bus_socket" scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket ---- time->Tue Jan 24 07:19:11 2006 type=PATH msg=audit(1138108751.178:11): item=0 flags=1 inode=1212726 dev=fd:00 mode=0140777 ouid=0 ogid=0 rdev=00:00 type=SOCKETCALL msg=audit(1138108751.178:11): nargs=3 a0=3 a1=bfd631ca a2=21 type=SOCKADDR msg=audit(1138108751.178:11): saddr=01002F7661722F72756E2F646275732F73797374656D5F6275735F736F636B6574 type=AVC_PATH msg=audit(1138108751.178:11): path="/var/run/dbus/system_bus_socket" type=SYSCALL msg=audit(1138108751.178:11): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfd63190 a2=9d85d4 a3=1f items=1 pid=2127 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-add-selinu" exe="/usr/libexec/hald-add-selinux-mount-option" type=AVC msg=audit(1138108751.178:11): avc: denied { connectto } for pid=2127 comm="hald-add-selinu" name="system_bus_socket" scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket ---- time->Tue Jan 24 07:19:11 2006 type=PATH msg=audit(1138108751.310:12): item=0 flags=1 inode=1212726 dev=fd:00 mode=0140777 ouid=0 ogid=0 rdev=00:00 type=SOCKETCALL msg=audit(1138108751.310:12): nargs=3 a0=3 a1=bf93bcba a2=21 type=SOCKADDR msg=audit(1138108751.310:12): saddr=01002F7661722F72756E2F646275732F73797374656D5F6275735F736F636B6574 type=AVC_PATH msg=audit(1138108751.310:12): path="/var/run/dbus/system_bus_socket" type=SYSCALL msg=audit(1138108751.310:12): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bf93bc80 a2=65f5d4 a3=1f items=1 pid=2129 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-add-selinu" exe="/usr/libexec/hald-add-selinux-mount-option" type=AVC msg=audit(1138108751.310:12): avc: denied { connectto } for pid=2129 comm="hald-add-selinu" name="system_bus_socket" scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket ---- time->Tue Jan 24 07:19:11 2006 type=PATH msg=audit(1138108751.894:13): item=0 flags=1 inode=1212726 dev=fd:00 mode=0140777 ouid=0 ogid=0 rdev=00:00 type=SOCKETCALL msg=audit(1138108751.894:13): nargs=3 a0=3 a1=bfa2b4fa a2=21 type=SOCKADDR msg=audit(1138108751.894:13): saddr=01002F7661722F72756E2F646275732F73797374656D5F6275735F736F636B6574 type=AVC_PATH msg=audit(1138108751.894:13): path="/var/run/dbus/system_bus_socket" type=SYSCALL msg=audit(1138108751.894:13): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfa2b4c0 a2=1805d4 a3=1f items=1 pid=2136 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-add-selinu" exe="/usr/libexec/hald-add-selinux-mount-option" type=AVC msg=audit(1138108751.894:13): avc: denied { connectto } for pid=2136 comm="hald-add-selinu" name="system_bus_socket" scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket ---- time->Tue Jan 24 07:19:12 2006 type=PATH msg=audit(1138108752.022:14): item=0 flags=1 inode=1212726 dev=fd:00 mode=0140777 ouid=0 ogid=0 rdev=00:00 type=SOCKETCALL msg=audit(1138108752.022:14): nargs=3 a0=d a1=bfaf0aba a2=21 type=SOCKADDR msg=audit(1138108752.022:14): saddr=01002F7661722F72756E2F646275732F73797374656D5F6275735F736F636B6574 type=AVC_PATH msg=audit(1138108752.022:14): path="/var/run/dbus/system_bus_socket" type=SYSCALL msg=audit(1138108752.022:14): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfaf0a80 a2=2e65d4 a3=1f items=1 pid=2107 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald" exe="/usr/sbin/hald" type=AVC msg=audit(1138108752.022:14): avc: denied { connectto } for pid=2107 comm="hald" name="system_bus_socket" scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket From mayerf at tresys.com Tue Jan 24 14:36:19 2006 From: mayerf at tresys.com (Frank Mayer) Date: Tue, 24 Jan 2006 09:36:19 -0500 Subject: Opening keynote annouce for SELinux Symposium Message-ID: <00de01c620f3$8b8c5750$8c0d010a@columbia.tresys.com> For those of you planning to attend the SELinux Symposium, we just annouced the opening keynote speaker. I've attached the press release below. Frank -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Opening Keynote Speaker Announced for the Second Security-Enhanced Linux Symposium and Developer Summit Baltimore, MD - (January 23, 2006) - Steve Walker, President of Steve Walker & Associates and Managing Partner of Walker Ventures, will be the opening keynote speaker for the second annual Security-Enhanced Linux (SELinux) Symposium scheduled for February 27-March 3, 2006 in Baltimore, Maryland. Mr. Walker has the unique experience of having participated in the evolution of computer security over the past 35 years from its early research within the U.S. Department of Defense (DoD) through its explosion into today's world-wide products and services business. He is a 22-year veteran of the DoD at the National Security Agency, the Advanced Research Projects Agency and the Office of the Secretary of Defense. Mr. Walker was one of the elite members of a team responsible for the development of the ARPAnet, the legendary breakthrough messaging system that allowed the birth of the Internet as we know it today. He is also nationally recognized for his pioneering work on the DoD Computer Security Initiative and establishment of the National Computer Security Center within the U.S. In addition, Mr. Walker was the President and Chief Executive Officer of Trusted Information Systems, Inc. (TIS), which he founded in 1983. Before its purchase by Network Associates, TIS had become a publicly traded company, employed more than 350 people, and had offices throughout the world. Having its foundation in network security advanced research and development, TIS was responsible for creating revolutionary technologies including the world's most secure firewall, Gauntlet, and the first fully exportable encryption, RecoverKey. Currently, Mr. Walker serves as President of Steve Walker & Associates and Managing Partner of Walker Ventures, a venture capital fund investing in early-stage technology companies. Mr. Walker will present a keynote address entitled "The Road to Practical Mandatory Security in Mainstream Operating Systems - an historical perspective." In this address, Mr. Walker will share his insights on the technological, political, and business challenges that have been overcome the past 30+ years on the road to the practical mandatory access control features SELinux brings to the mainstream. About the SELinux Symposium The Security-Enhanced Linux (SELinux) Symposium is an annual exchange of ideas, technology, and research involving SELinux. SELinux is technology that adds flexible, strong mandatory access control security to Linux. The Second Symposium is scheduled for February 27-March 3, 2006 in Baltimore, Maryland and is sponsored by Hewlett-Packard, IBM, Red Hat, Tresys Technology, and Trusted Computer Solutions. The event brings together experts from business, government, and academia to share research, development, and application experiences using SELinux. For information on registration and sponsorship opportunities, see www.selinux-symposium.org or info at selinux-symposium.org. From selinux at gmail.com Tue Jan 24 15:00:24 2006 From: selinux at gmail.com (Tom London) Date: Tue, 24 Jan 2006 07:00:24 -0800 Subject: new avcs In-Reply-To: References: Message-ID: <4c4ba1530601240700k9ec4b86n98b02903dab29321@mail.gmail.com> See if dbus-daemon is running as initrc_t: 'ps alxZ | grep dbus-daemon' If so, do a 'ls -lZ /bin/dbus-daemon'. If it reports as bin_t, it needs to be 'fixed'. Try 'chcon -t system_dbusd_exec_t /bin/dbus-daemon' , and reboot. tom From dravet at hotmail.com Tue Jan 24 15:45:53 2006 From: dravet at hotmail.com (Jason Dravet) Date: Tue, 24 Jan 2006 09:45:53 -0600 Subject: new avcs In-Reply-To: <4c4ba1530601240700k9ec4b86n98b02903dab29321@mail.gmail.com> Message-ID: >See if dbus-daemon is running as initrc_t: >'ps alxZ | grep dbus-daemon' > >If so, do a 'ls -lZ /bin/dbus-daemon'. If it reports as bin_t, it >needs to be 'fixed'. > >Try 'chcon -t system_dbusd_exec_t /bin/dbus-daemon' , and reboot. You are right the dbus-daemon was running as bin_t. The chcon fixed it. Thanks, Jason From dougdavidson at direcway.com Tue Jan 24 16:53:05 2006 From: dougdavidson at direcway.com (Doug) Date: Tue, 24 Jan 2006 11:53:05 -0500 Subject: Fedora C-4 Message-ID: <43D65B71.9070400@direcway.com> On Jan. 22, 2006 I wrote: After upgrading from Fedora core3 to core4 my Nero-linux would not open. I installed the selinux policy targeted update and the Nero-linux problem was fixed but a new problem arose, now my HP Device Manager will not open. I have reinstalled HPLIP, checked everything I can find documented that might cause this and have resorted to living with the problem. If anyone has a suggestion I would be grateful for the help. dougdavidson at direcway.com I have discovered through trial and error (not knowledge YET) my problem can be fixed, by doing the following. Select in order; System Settings, Security Level, Selinux, Modify Selinux Policy, Other, place a check in (box)HPLIP_Disable_Trans. Close and re-boot. Now HP Device Manager works and so does the Scanner. Does anyone know what the consequence of this action might be, if any? dougdavidson at direcway.com From dwalsh at redhat.com Wed Jan 25 17:05:05 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 25 Jan 2006 12:05:05 -0500 Subject: invalid context root:sysadm_r:initrc_t? In-Reply-To: <43D1E9EA.9000402@feuerpokemon.de> References: <43D1E9EA.9000402@feuerpokemon.de> Message-ID: <43D7AFC1.7040605@redhat.com> dragoran wrote: > hello I found this errors in dmesg on a FC4 system using > selinux-policy-targeted-1.27.1-2.16: > audit(1137825680.353:2): security_compute_sid: invalid context > root:sysadm_r:initrc_t for scontext=root:sysadm_r:unconfined_t > tcontext=system_u:object_r:initrc_exec_t tclass=process > audit(1137825680.617:3): security_compute_sid: invalid context > root:sysadm_r:initrc_t for scontext=root:sysadm_r:unconfined_t > tcontext=system_u:object_r:initrc_exec_t tclass=process > what are this errors? what does invalid context means? > This means you have a process running in the sysadm_r and it is not allowed to execute the initrc_exec_t program. This should not happen. How did you get the process in the sysadm_r? Did you run newrole? > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Wed Jan 25 17:06:54 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 25 Jan 2006 12:06:54 -0500 Subject: su, context(selinux?) 2nd prompt In-Reply-To: References: <43D4FAAF.6020108@redhat.com> Message-ID: <43D7B02E.7070004@redhat.com> Rex Dieter wrote: > Daniel J Walsh wrote: > > > >>>> On Mon, 23 Jan 2006, Rex Dieter wrote: >>>> >>>> >>>> >>>>> With a recent update of CentOS4, su's behavior has changed, in that >>>>> after >>>>> prompting for password, also prompts for (selinux?) context. I'm >>>>> seeing something like: >>>>> $ su >>>>> Password: >>>>> Your default context is root:system_r:unconfined_t. >>>>> >>>>> Do you want to choose a different one? [n] >>>>> >>>>> >>>>> kde's kdesu barfs on this second prompt. Any way to disable this >>>>> second prompt? >>>>> > > >> Remove multiple from the pam file. >> > > editing /etc/pam.d/su, changing > session required /lib/security/$ISA/pam_selinux.so open multiple > to > session required /lib/security/$ISA/pam_selinux.so open > > Did the trick, thanks Dan! > > # rpm -q -f /etc/pam.d/su > coreutils-5.2.1-31.2 > > You can actually remove the pam_selinux.so lines from the su file altogether. We have done this for FC5 and it works fine. In strict or MLS Policy you will be required to run newrole but in targeted everything should just work. Dan > A bug in coreutils-5.2.1-31.2 then? > > -- Rex > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From dwalsh at redhat.com Wed Jan 25 17:08:46 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 25 Jan 2006 12:08:46 -0500 Subject: Fedora C-4 In-Reply-To: <43D65B71.9070400@direcway.com> References: <43D65B71.9070400@direcway.com> Message-ID: <43D7B09E.1000203@redhat.com> Doug wrote: > On Jan. 22, 2006 I wrote: After upgrading from Fedora core3 to core4 > my Nero-linux would not open. I installed the selinux policy targeted > update and the Nero-linux problem was fixed but a new problem arose, > now my HP Device Manager will not open. I have reinstalled HPLIP, > checked everything I can find documented that might cause this and > have resorted to living with the problem. If anyone has a suggestion I > would be grateful for the help. dougdavidson at direcway.com > > I have discovered through trial and error (not knowledge YET) my > problem can be fixed, by doing the following. Select in order; System > Settings, Security Level, Selinux, Modify Selinux Policy, Other, place > a check in (box)HPLIP_Disable_Trans. > Close and re-boot. Now HP Device Manager works and so does the > Scanner. Does anyone know what the consequence of this action might > be, if any? dougdavidson at direcway.com > Are you seeing AVC messages in /var/log/messages of /var/log/audit/audit.log? > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From netllama at gmail.com Thu Jan 26 00:16:21 2006 From: netllama at gmail.com (Lonni J Friedman) Date: Wed, 25 Jan 2006 16:16:21 -0800 Subject: 3rd party shared objects won't work without disabling SELinux Message-ID: <7c1574a90601251616v6c99efdet180973036aa977de@mail.gmail.com> Hello, I'm working on an application that requires 3rd party (outside of what ships with FC) shared libraries. With FC4, I'm not having any problems. Up until just a few days ago, everything was working in FC5-test2 as well. However it seems that some update suddenly broke things in such a way that unless I completely disable SELinux, I cannot load/access the shared objects that I installed. When I attempt to do so, I get the following error: cannot enable executable stack as shared object requires: Permission denied Can someone point out what SELinux foo I might be missing here? thanks, Lonni From bruce.ecroyd at gmail.com Thu Jan 26 03:51:01 2006 From: bruce.ecroyd at gmail.com (Bruce Ecroyd) Date: Wed, 25 Jan 2006 22:51:01 -0500 Subject: Error sending status request (Operation not permitted) Message-ID: I recently switched from FC4 targeted (enforcing) to strict (permissive) using selinux-policy-strict-1.27.1-2.16.noarch.rpm. I did a touch /.autorelabel before rebooting. I see this: [bruce at BorgCube ~]$ su - Password: Error sending status request (Operation not permitted) [root at BorgCube ~]# The last part of the /var/log/audit/audit.log shows: type=SYSCALL msg=audit(1138247001.111:13162965): arch=40000003 syscall=5 success=yes exit=3 a0=866125b a1=c2 a2=180 a3=3a8083 items=1 pid=8250 auid=4294967295 uid=501 gid=100 euid=0 suid=0 fsuid=0 egid=100 sgid=100 fsgid=100 comm="su" exe="/bin/su" type=AVC msg=audit(1138247001.111:13162965): avc: denied { create } for pid=8250 comm="su" name=.xauthVpNVFy scontext=user_u:user_r:user_t tcontext=user_u:object_r:sysadm_home_dir_t tclass=file type=AVC msg=audit(1138247001.111:13162965): avc: denied { add_name } for pid=8250 comm="su" name=.xauthVpNVFy scontext=user_u:user_r:user_t tcontext=root:object_r:sysadm_home_dir_t tclass=dir type=AVC msg=audit(1138247001.111:13162965): avc: denied { write } for pid=8250 comm="su" name=root dev=dm-0 ino=11392129 scontext=user_u:user_r:user_t tcontext=root:object_r:sysadm_home_dir_t tclass=dir type=SYSCALL msg=audit(1138247001.111:13162967): arch=40000003 syscall=207 success=yes exit=0 a0=3 a1=0 a2=0 a3=0 items=0 pid=8250 auid=4294967295 uid=501 gid=100 euid=0 suid=0 fsuid=0 egid=100 sgid=100 fsgid=100 comm="su" exe="/bin/su" type=AVC msg=audit(1138247001.111:13162967): avc: denied { setattr } for pid=8250 comm="su" name=.xauthVpNVFy dev=dm-0 ino=11392172 scontext=user_u:user_r:user_t tcontext=user_u:object_r:sysadm_home_dir_t tclass=file type=USER msg=audit(1138247001.325:13165423): user pid=8250 uid=501 auid=4294967295 msg='PAM session open: user=root exe=/bin/su (hostname=?, addr=?, terminal=pts/2 result=Success)' Any ideas? If I change to strict, enforcing, will this prevent me from su to root? Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at tycho.nsa.gov Thu Jan 26 13:35:44 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 26 Jan 2006 08:35:44 -0500 Subject: 3rd party shared objects won't work without disabling SELinux In-Reply-To: <7c1574a90601251616v6c99efdet180973036aa977de@mail.gmail.com> References: <7c1574a90601251616v6c99efdet180973036aa977de@mail.gmail.com> Message-ID: <1138282544.13075.97.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-01-25 at 16:16 -0800, Lonni J Friedman wrote: > Hello, > I'm working on an application that requires 3rd party (outside of what > ships with FC) shared libraries. With FC4, I'm not having any > problems. Up until just a few days ago, everything was working in > FC5-test2 as well. > > However it seems that some update suddenly broke things in such a way > that unless I completely disable SELinux, I cannot load/access the > shared objects that I installed. When I attempt to do so, I get the > following error: > cannot enable executable stack as shared object requires: Permission denied > > Can someone point out what SELinux foo I might be missing here? For discussion of the same issue for another application and DSO, see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178924 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170187 Can you run 'execstack -c' on the shared object? If that succeeds, does the program then work? Also, check your /var/log/audit/audit.log for any other AVC denials. -- Stephen Smalley National Security Agency From craigwhite at azapple.com Thu Jan 26 14:25:12 2006 From: craigwhite at azapple.com (Craig White) Date: Thu, 26 Jan 2006 07:25:12 -0700 Subject: /usr/share - self inflicted issue Message-ID: <1138285512.23283.18.camel@lin-workstation.azapple.com> My main desktop, I was trying to upgrade from FC-3 to FC-4. I was a little short of space in /usr partition so I moved /usr/share to /home/share and symlinked it back. This seemed all and good but that does cause a cups issue. the only clues I ever get are... E [26/Jan/2006:07:02:22 -0700] LoadBanners: Unable to open banner directory "/usr/share/cups/banners": Permission denied /var/log/cups/error_log E [26/Jan/2006:07:02:22 -0700] LoadPPDs: Unable to open PPD directory "/usr/share/cups/model": Permission denied but those directories **seem to be ok** # ls -Zld /usr/share/cups/model /usr/share/cups/banners/ drwxr-xr-x 2 system_u:object_r:cupsd_etc_t root root 4096 Jan 16 18:29 /usr/share/cups/banners/ drwxr-xr-x 2 system_u:object_r:cupsd_etc_t root root 4096 Jan 16 18:29 /usr/share/cups/model on my CentOS-4 system...they are different # ls -Zld /usr/share/cups/model /usr/share/cups/banners/ drwxr-xr-x 2 system_u:object_r:usr_t root root 4096 Dec 27 07:12 /usr/share/cups/banners/ drwxr-xr-x 2 system_u:object_r:usr_t root root 4096 Dec 27 07:12 /usr/share/cups/model The things I try to fix this aren't working... # fixfiles -R cups restore /sbin/restorecon: error while labeling files under /usr/share/cups and on and on for every file/folder in the tree # chcon -t system_u:object_r:usr_t /usr/share/cups/ chcon: couldn't compute security context from system_u:object_r:cupsd_etc_t and I am stumped...suggestions anyone? Thanks Craig From paul at city-fan.org Thu Jan 26 14:38:05 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 26 Jan 2006 14:38:05 +0000 Subject: /usr/share - self inflicted issue In-Reply-To: <1138285512.23283.18.camel@lin-workstation.azapple.com> References: <1138285512.23283.18.camel@lin-workstation.azapple.com> Message-ID: <43D8DECD.5010804@city-fan.org> Craig White wrote: > My main desktop, I was trying to upgrade from FC-3 to FC-4. > > I was a little short of space in /usr partition so I moved /usr/share > to /home/share and symlinked it back. > > This seemed all and good but that does cause a cups issue. > > the only clues I ever get are... > > E [26/Jan/2006:07:02:22 -0700] LoadBanners: Unable to open banner > directory "/usr/share/cups/banners": Permission denied > > /var/log/cups/error_log > E [26/Jan/2006:07:02:22 -0700] LoadPPDs: Unable to open PPD directory > "/usr/share/cups/model": Permission denied > > but those directories **seem to be ok** > > # ls -Zld /usr/share/cups/model /usr/share/cups/banners/ > drwxr-xr-x 2 system_u:object_r:cupsd_etc_t root root 4096 Jan 16 > 18:29 /usr/share/cups/banners/ > drwxr-xr-x 2 system_u:object_r:cupsd_etc_t root root 4096 Jan 16 > 18:29 /usr/share/cups/model > > on my CentOS-4 system...they are different > # ls -Zld /usr/share/cups/model /usr/share/cups/banners/ > drwxr-xr-x 2 system_u:object_r:usr_t root root 4096 Dec 27 > 07:12 /usr/share/cups/banners/ > drwxr-xr-x 2 system_u:object_r:usr_t root root 4096 Dec 27 > 07:12 /usr/share/cups/model Everything under /usr/share/cups is system_u:object_r:cupsd_etc_t on my FC4 boxes. What are the actual AVCs you're getting? # ausearch -m avc,selinux_err Paul. From sds at tycho.nsa.gov Thu Jan 26 14:55:55 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 26 Jan 2006 09:55:55 -0500 Subject: /usr/share - self inflicted issue In-Reply-To: <1138285512.23283.18.camel@lin-workstation.azapple.com> References: <1138285512.23283.18.camel@lin-workstation.azapple.com> Message-ID: <1138287355.13075.137.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-01-26 at 07:25 -0700, Craig White wrote: > My main desktop, I was trying to upgrade from FC-3 to FC-4. > > I was a little short of space in /usr partition so I moved /usr/share > to /home/share and symlinked it back. > > This seemed all and good but that does cause a cups issue. You need to tell SELinux to label your /home/share tree as it would the /usr/share tree, and then relabel, e.g.: # sed -n -e "/\/usr\/share/s/\/usr\/share\//\/home\/share\//p" /etc/selinux/targeted/contexts/files/file_contexts > /etc/selinux/targeted/contexts/files/file_contexts.local # restorecon -R /home/share -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu Jan 26 15:00:29 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 26 Jan 2006 10:00:29 -0500 Subject: /usr/share - self inflicted issue In-Reply-To: <1138287355.13075.137.camel@moss-spartans.epoch.ncsc.mil> References: <1138285512.23283.18.camel@lin-workstation.azapple.com> <1138287355.13075.137.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1138287629.13075.142.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-01-26 at 09:56 -0500, Stephen Smalley wrote: > On Thu, 2006-01-26 at 07:25 -0700, Craig White wrote: > > My main desktop, I was trying to upgrade from FC-3 to FC-4. > > > > I was a little short of space in /usr partition so I moved /usr/share > > to /home/share and symlinked it back. > > > > This seemed all and good but that does cause a cups issue. > > You need to tell SELinux to label your /home/share tree as it would > the /usr/share tree, and then relabel, e.g.: > # sed -n -e "/\/usr\/share/s/\/usr\/share\//\/home\/share\//p" /etc/selinux/targeted/contexts/files/file_contexts > /etc/selinux/targeted/contexts/files/file_contexts.local > > # restorecon -R /home/share Hmm...nevermind, you said that they are already labeled correctly later in your message, although I'm a little unclear as to why that is, unless they were just preserved when you copied them. But you likely want the above anyway to ensure that they are preserved upon any subsequent relabels. So, as the other responder asked, what AVC denials are you getting? -- Stephen Smalley National Security Agency From paul at city-fan.org Thu Jan 26 15:01:51 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 26 Jan 2006 15:01:51 +0000 Subject: /usr/share - self inflicted issue In-Reply-To: <1138286546.23283.21.camel@lin-workstation.azapple.com> References: <1138285512.23283.18.camel@lin-workstation.azapple.com> <43D8DECD.5010804@city-fan.org> <1138286546.23283.21.camel@lin-workstation.azapple.com> Message-ID: <43D8E45F.7070302@city-fan.org> Craig White wrote: > On Thu, 2006-01-26 at 14:38 +0000, Paul Howarth wrote: > >>Craig White wrote: >> >>>My main desktop, I was trying to upgrade from FC-3 to FC-4. >>> >>>I was a little short of space in /usr partition so I moved /usr/share >>>to /home/share and symlinked it back. >>> >>>This seemed all and good but that does cause a cups issue. >>> >>>the only clues I ever get are... >>> >>>E [26/Jan/2006:07:02:22 -0700] LoadBanners: Unable to open banner >>>directory "/usr/share/cups/banners": Permission denied >>> >>>/var/log/cups/error_log >>>E [26/Jan/2006:07:02:22 -0700] LoadPPDs: Unable to open PPD directory >>>"/usr/share/cups/model": Permission denied >>> >>>but those directories **seem to be ok** >>> >>># ls -Zld /usr/share/cups/model /usr/share/cups/banners/ >>>drwxr-xr-x 2 system_u:object_r:cupsd_etc_t root root 4096 Jan 16 >>>18:29 /usr/share/cups/banners/ >>>drwxr-xr-x 2 system_u:object_r:cupsd_etc_t root root 4096 Jan 16 >>>18:29 /usr/share/cups/model >>> >>>on my CentOS-4 system...they are different >>># ls -Zld /usr/share/cups/model /usr/share/cups/banners/ >>>drwxr-xr-x 2 system_u:object_r:usr_t root root 4096 Dec 27 >>>07:12 /usr/share/cups/banners/ >>>drwxr-xr-x 2 system_u:object_r:usr_t root root 4096 Dec 27 >>>07:12 /usr/share/cups/model >> >>Everything under /usr/share/cups is system_u:object_r:cupsd_etc_t on my >>FC4 boxes. What are the actual AVCs you're getting? >> >># ausearch -m avc,selinux_err > > ---- > for the purposes of brevity, I will only paste in the first > record...there are probably as many returned as there are files in > the /usr/share/cups tree like this... > > time->Mon Jan 16 16:33:00 2006 > type=PATH msg=audit(1137454380.947:5): item=0 > name="/usr/share/printconf/util" flags=1 inode=2 dev=03:02 mode=040755 > ouid=0 ogid=0 rdev=00:00 > type=CWD msg=audit(1137454380.947:5): cwd="/" > type=SYSCALL msg=audit(1137454380.947:5): arch=40000003 syscall=195 > success=no exit=-13 a0=bfa5a5b6 a1=bfa5a9b8 a2=b1eff4 a3=b7ec890c > items=1 pid=1974 aui > d=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > comm="printconf-backe" exe="/usr/bin/python" > type=AVC msg=audit(1137454380.947:5): avc: denied { read } for > pid=1974 comm="printconf-backe" name="share" dev=hda2 ino=12 > scontext=system_u:system_r: > cupsd_config_t tcontext=system_u:object_r:usr_t tclass=lnk_file It seems to be having problems with your symlink. Could you try doing a bind mount instead: # mount --bind /home/share /usr/share Paul. From sds at tycho.nsa.gov Thu Jan 26 15:12:41 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 26 Jan 2006 10:12:41 -0500 Subject: /usr/share - self inflicted issue In-Reply-To: <1138285512.23283.18.camel@lin-workstation.azapple.com> References: <1138285512.23283.18.camel@lin-workstation.azapple.com> Message-ID: <1138288361.13075.151.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-01-26 at 07:25 -0700, Craig White wrote: > The things I try to fix this aren't working... > > # fixfiles -R cups restore > /sbin/restorecon: error while labeling files under /usr/share/cups > and on and on for every file/folder in the tree > > # chcon -t system_u:object_r:usr_t /usr/share/cups/ > chcon: couldn't compute security context from > system_u:object_r:cupsd_etc_t On the last one, you specified a full context rather than just the type; the -t option expects only a type (e.g. usr_t). But you don't want just usr_t there anyway; you appear to have the right types on /usr/share/cups already. CentOS/RHEL likely doesn't have the cups policy at all yet. Not sure why your fixfiles command is failing; more detail would be helpful. One obvious possibility is that the cups policy might not allow access to search /home, thereby preventing it from reaching /home/share and /home/share/cups. So you would have to add a local.te file that allows such access. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu Jan 26 15:14:28 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 26 Jan 2006 10:14:28 -0500 Subject: /usr/share - self inflicted issue In-Reply-To: <1138288361.13075.151.camel@moss-spartans.epoch.ncsc.mil> References: <1138285512.23283.18.camel@lin-workstation.azapple.com> <1138288361.13075.151.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1138288468.13075.153.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-01-26 at 10:12 -0500, Stephen Smalley wrote: > One obvious possibility is that the cups policy might not allow access > to search /home, thereby preventing it from reaching /home/share > and /home/share/cups. So you would have to add a local.te file that > allows such access. If the above isn't clear, see the EXAMPLE section of the man page for audit2allow. -- Stephen Smalley National Security Agency From craigwhite at azapple.com Thu Jan 26 15:23:21 2006 From: craigwhite at azapple.com (Craig White) Date: Thu, 26 Jan 2006 08:23:21 -0700 Subject: /usr/share - self inflicted issue In-Reply-To: <1138288468.13075.153.camel@moss-spartans.epoch.ncsc.mil> References: <1138285512.23283.18.camel@lin-workstation.azapple.com> <1138288361.13075.151.camel@moss-spartans.epoch.ncsc.mil> <1138288468.13075.153.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1138289001.23283.41.camel@lin-workstation.azapple.com> On Thu, 2006-01-26 at 10:14 -0500, Stephen Smalley wrote: > On Thu, 2006-01-26 at 10:12 -0500, Stephen Smalley wrote: > > One obvious possibility is that the cups policy might not allow access > > to search /home, thereby preventing it from reaching /home/share > > and /home/share/cups. So you would have to add a local.te file that > > allows such access. > > If the above isn't clear, see the EXAMPLE section of the man page for > audit2allow. ---- on RHEL - I was able to install selinux-targeted-policy-sources and that gave me the resources to create the local.te file. on FC-4, I execute 'yum install selinux-targeted-policy-sources' and it can't find it. What is the package called in FC-4? Craig From selinux at gmail.com Thu Jan 26 15:26:15 2006 From: selinux at gmail.com (Tom London) Date: Thu, 26 Jan 2006 07:26:15 -0800 Subject: /etc/blkid.tab, /etc/avahi/etc/localtime Message-ID: <4c4ba1530601260726o701363d2ma2212c7293a67471@mail.gmail.com> Running targeted/enforcing, latest rawhide. I get these with 'restorecon -v -R /etc': restorecon reset /etc/avahi/etc/localtime context system_u:object_r:locale_t->system_u:object_r:etc_t restorecon reset /etc/blkid.tab context user_u:object_r:etc_t->system_u:object_r:etc_runtime_t First, I believe the avahi chroots to /etc/avahi, so shouldn't its 'local copy' of localtime be locale_t? Second, checking /var/log/messages, I get: Jan 26 06:50:41 localhost kernel: audit(1138286986.121:2): avc: denied { write } for pid=1554 comm="mount" name="blkid.tab" dev=dm-0 ino=1275806 scontext=system_u:system_r:mount_t:s0 tcontext=user_u:object_r:etc_t:s0 tclass=file Jan 26 06:50:41 localhost kernel: floppy0: no floppy controllers found Jan 26 06:50:41 localhost kernel: audit(1138286987.665:3): avc: denied { write } for pid=1602 comm="swapon" name="blkid.tab" dev=dm-0 ino=1275806 scontext=system_u:system_r:fsadm_t:s0 tcontext=user_u:object_r:etc_t:s0 tclass=file Jan 26 06:50:41 localhost kernel: Adding 1048568k swap on /dev/VolGroup00/LogVol01. Priority:-1 extents:1 across:1048568k So it looks like blkid.tab's type is getting (periodically) wedged. I'm guessing this occurs when I do a 'mount' (manual) or insert a usb drive of some sort. More needed here to figure out? tom -- Tom London From sds at tycho.nsa.gov Thu Jan 26 15:34:29 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 26 Jan 2006 10:34:29 -0500 Subject: /usr/share - self inflicted issue In-Reply-To: <1138289001.23283.41.camel@lin-workstation.azapple.com> References: <1138285512.23283.18.camel@lin-workstation.azapple.com> <1138288361.13075.151.camel@moss-spartans.epoch.ncsc.mil> <1138288468.13075.153.camel@moss-spartans.epoch.ncsc.mil> <1138289001.23283.41.camel@lin-workstation.azapple.com> Message-ID: <1138289669.13075.162.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-01-26 at 08:23 -0700, Craig White wrote: > On Thu, 2006-01-26 at 10:14 -0500, Stephen Smalley wrote: > > On Thu, 2006-01-26 at 10:12 -0500, Stephen Smalley wrote: > > > One obvious possibility is that the cups policy might not allow access > > > to search /home, thereby preventing it from reaching /home/share > > > and /home/share/cups. So you would have to add a local.te file that > > > allows such access. > > > > If the above isn't clear, see the EXAMPLE section of the man page for > > audit2allow. > ---- > on RHEL - I was able to install selinux-targeted-policy-sources and that > gave me the resources to create the local.te file. > > on FC-4, I execute 'yum install selinux-targeted-policy-sources' and it > can't find it. What is the package called in FC-4? That's selinux-policy-targeted-sources. Should be the same on RHEL. As a heads up, the policy*sources packages go away in FC5; the new modular policy support eliminates the need for base policy sources to perform local additions, so policy sources are only in the .src.rpm in FC5. -- Stephen Smalley National Security Agency From craigwhite at azapple.com Thu Jan 26 15:46:03 2006 From: craigwhite at azapple.com (Craig White) Date: Thu, 26 Jan 2006 08:46:03 -0700 Subject: /usr/share - self inflicted issue In-Reply-To: <1138289669.13075.162.camel@moss-spartans.epoch.ncsc.mil> References: <1138285512.23283.18.camel@lin-workstation.azapple.com> <1138288361.13075.151.camel@moss-spartans.epoch.ncsc.mil> <1138288468.13075.153.camel@moss-spartans.epoch.ncsc.mil> <1138289001.23283.41.camel@lin-workstation.azapple.com> <1138289669.13075.162.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1138290363.23283.47.camel@lin-workstation.azapple.com> On Thu, 2006-01-26 at 10:34 -0500, Stephen Smalley wrote: > On Thu, 2006-01-26 at 08:23 -0700, Craig White wrote: > > On Thu, 2006-01-26 at 10:14 -0500, Stephen Smalley wrote: > > > On Thu, 2006-01-26 at 10:12 -0500, Stephen Smalley wrote: > > > > One obvious possibility is that the cups policy might not allow access > > > > to search /home, thereby preventing it from reaching /home/share > > > > and /home/share/cups. So you would have to add a local.te file that > > > > allows such access. > > > > > > If the above isn't clear, see the EXAMPLE section of the man page for > > > audit2allow. > > ---- > > on RHEL - I was able to install selinux-targeted-policy-sources and that > > gave me the resources to create the local.te file. > > > > on FC-4, I execute 'yum install selinux-targeted-policy-sources' and it > > can't find it. What is the package called in FC-4? > > That's selinux-policy-targeted-sources. Should be the same on RHEL. > > As a heads up, the policy*sources packages go away in FC5; the new > modular policy support eliminates the need for base policy sources to > perform local additions, so policy sources are only in the .src.rpm in > FC5. ---- Arrgh E [26/Jan/2006:08:40:36 -0700] LoadPPDs: Unable to open PPD directory "/usr/share/cups/model": Permission denied this is after... cd /etc/selinux/targeted/src/policy /usr/bin/audit2allow -i < /var/log/audit/audit.log \ >> domains/misc/local.te which resulted in this... # cat domains/misc/local.te # Local customization of existing policy should be done in this file. # If you are creating brand new policy for a new "target" domain, you # need to create a type enforcement (.te) file in domains/program # and a file context (.fc) file in file_context/program. allow canna_t usr_t:lnk_file read; allow cupsd_config_t unconfined_t:fifo_file write; allow cupsd_config_t user_home_t:file read; allow cupsd_config_t usr_t:lnk_file read; allow cupsd_t home_root_t:dir search; allow hald_t usr_t:lnk_file read; allow restorecon_t usr_t:lnk_file read; allow unlabeled_t fs_t:filesystem associate; and then... # make reload # fixfiles -R cups restore # service cups restart ;-( Craig From sds at tycho.nsa.gov Thu Jan 26 16:12:07 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 26 Jan 2006 11:12:07 -0500 Subject: /usr/share - self inflicted issue In-Reply-To: <1138290363.23283.47.camel@lin-workstation.azapple.com> References: <1138285512.23283.18.camel@lin-workstation.azapple.com> <1138288361.13075.151.camel@moss-spartans.epoch.ncsc.mil> <1138288468.13075.153.camel@moss-spartans.epoch.ncsc.mil> <1138289001.23283.41.camel@lin-workstation.azapple.com> <1138289669.13075.162.camel@moss-spartans.epoch.ncsc.mil> <1138290363.23283.47.camel@lin-workstation.azapple.com> Message-ID: <1138291927.13075.179.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-01-26 at 08:46 -0700, Craig White wrote: > E [26/Jan/2006:08:40:36 -0700] LoadPPDs: Unable to open PPD directory > "/usr/share/cups/model": Permission denied > > this is after... > > cd /etc/selinux/targeted/src/policy > /usr/bin/audit2allow -i < /var/log/audit/audit.log \ > >> domains/misc/local.te > > which resulted in this... > # cat domains/misc/local.te > # Local customization of existing policy should be done in this file. > # If you are creating brand new policy for a new "target" domain, you > # need to create a type enforcement (.te) file in domains/program > # and a file context (.fc) file in file_context/program. > > allow canna_t usr_t:lnk_file read; > allow cupsd_config_t unconfined_t:fifo_file write; > allow cupsd_config_t user_home_t:file read; > allow cupsd_config_t usr_t:lnk_file read; > allow cupsd_t home_root_t:dir search; > allow hald_t usr_t:lnk_file read; > allow restorecon_t usr_t:lnk_file read; > allow unlabeled_t fs_t:filesystem associate; That last one is particularly suspect; what audit message contained unlabeled_t? > and then... > # make reload > # fixfiles -R cups restore That shouldn't have been necessary, as you didn't change the file_contexts again. Only need to relabel upon changing file_contexts, not policy changes. > # service cups restart Check those audit messages again for anything new. It may be that it got further but ran into another denial later on. -- Stephen Smalley National Security Agency From craigwhite at azapple.com Thu Jan 26 16:19:15 2006 From: craigwhite at azapple.com (Craig White) Date: Thu, 26 Jan 2006 09:19:15 -0700 Subject: /usr/share - self inflicted issue [SOLVED] In-Reply-To: <1138291927.13075.179.camel@moss-spartans.epoch.ncsc.mil> References: <1138285512.23283.18.camel@lin-workstation.azapple.com> <1138288361.13075.151.camel@moss-spartans.epoch.ncsc.mil> <1138288468.13075.153.camel@moss-spartans.epoch.ncsc.mil> <1138289001.23283.41.camel@lin-workstation.azapple.com> <1138289669.13075.162.camel@moss-spartans.epoch.ncsc.mil> <1138290363.23283.47.camel@lin-workstation.azapple.com> <1138291927.13075.179.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1138292355.32576.11.camel@lin-workstation.azapple.com> On Thu, 2006-01-26 at 11:12 -0500, Stephen Smalley wrote: > On Thu, 2006-01-26 at 08:46 -0700, Craig White wrote: > > E [26/Jan/2006:08:40:36 -0700] LoadPPDs: Unable to open PPD directory > > "/usr/share/cups/model": Permission denied > > > > this is after... > > > > cd /etc/selinux/targeted/src/policy > > /usr/bin/audit2allow -i < /var/log/audit/audit.log \ > > >> domains/misc/local.te > > > > which resulted in this... > > # cat domains/misc/local.te > > # Local customization of existing policy should be done in this file. > > # If you are creating brand new policy for a new "target" domain, you > > # need to create a type enforcement (.te) file in domains/program > > # and a file context (.fc) file in file_context/program. > > > > allow canna_t usr_t:lnk_file read; > > allow cupsd_config_t unconfined_t:fifo_file write; > > allow cupsd_config_t user_home_t:file read; > > allow cupsd_config_t usr_t:lnk_file read; > > allow cupsd_t home_root_t:dir search; > > allow hald_t usr_t:lnk_file read; > > allow restorecon_t usr_t:lnk_file read; > > allow unlabeled_t fs_t:filesystem associate; > > That last one is particularly suspect; what audit message contained > unlabeled_t? > > > and then... > > # make reload > > # fixfiles -R cups restore > > That shouldn't have been necessary, as you didn't change the > file_contexts again. Only need to relabel upon changing file_contexts, > not policy changes. > > > # service cups restart > > Check those audit messages again for anything new. It may be that it > got further but ran into another denial later on. ---- you guys are awesome - I think it took both yours and Paul's suggestions to make it work. I am writing this up in case anyone travels down my path of self-inflicted wounds. The symlinked directory seemed to cause the problem - the steps I took to fix it are: removed the symlinked directory... # rm /usr/share mounted it via the bind method Paul suggested... # mount --bind /home/share /usr/share create the contexts for the new location per Steven's suggestion # sed -n -e "/\/usr\/share/s/\/usr\/share\//\/home\/share\//p" \ /etc/selinux/targeted/contexts/files/file_contexts \ > /etc/selinux/targeted/contexts/files/file_contexts.local also (not sure that this was necessary) # cd /etc/selinux/targeted/src/policy # /usr/bin/audit2allow -i < /var/log/audit/audit.log \ >> domains/misc/local.te # make reload then fix the contexts for the entire tree... # restorecon -R /usr/share restart cups daemon # service cups restart and I am printing again...Thanks to both of you...you guys are awesome. Craig From sds at tycho.nsa.gov Thu Jan 26 16:27:26 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 26 Jan 2006 11:27:26 -0500 Subject: /usr/share - self inflicted issue In-Reply-To: <1138291927.13075.179.camel@moss-spartans.epoch.ncsc.mil> References: <1138285512.23283.18.camel@lin-workstation.azapple.com> <1138288361.13075.151.camel@moss-spartans.epoch.ncsc.mil> <1138288468.13075.153.camel@moss-spartans.epoch.ncsc.mil> <1138289001.23283.41.camel@lin-workstation.azapple.com> <1138289669.13075.162.camel@moss-spartans.epoch.ncsc.mil> <1138290363.23283.47.camel@lin-workstation.azapple.com> <1138291927.13075.179.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1138292846.13075.187.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-01-26 at 11:12 -0500, Stephen Smalley wrote: > On Thu, 2006-01-26 at 08:46 -0700, Craig White wrote: > > E [26/Jan/2006:08:40:36 -0700] LoadPPDs: Unable to open PPD directory > > "/usr/share/cups/model": Permission denied > > > > this is after... > > > > cd /etc/selinux/targeted/src/policy > > /usr/bin/audit2allow -i < /var/log/audit/audit.log \ > > >> domains/misc/local.te > > > > which resulted in this... > > # cat domains/misc/local.te > > # Local customization of existing policy should be done in this file. > > # If you are creating brand new policy for a new "target" domain, you > > # need to create a type enforcement (.te) file in domains/program > > # and a file context (.fc) file in file_context/program. > > > > allow canna_t usr_t:lnk_file read; > > allow cupsd_config_t unconfined_t:fifo_file write; > > allow cupsd_config_t user_home_t:file read; > > allow cupsd_config_t usr_t:lnk_file read; > > allow cupsd_t home_root_t:dir search; > > allow hald_t usr_t:lnk_file read; > > allow restorecon_t usr_t:lnk_file read; > > allow unlabeled_t fs_t:filesystem associate; > > That last one is particularly suspect; what audit message contained > unlabeled_t? > > > and then... > > # make reload > > # fixfiles -R cups restore > > That shouldn't have been necessary, as you didn't change the > file_contexts again. Only need to relabel upon changing file_contexts, > not policy changes. > > > # service cups restart > > Check those audit messages again for anything new. It may be that it > got further but ran into another denial later on. It is also possible that a denial is not being audited due to a dontaudit rule in the policy (to silence noisy audit messages that happen due to unnecessary access attempts by applications and library functions). Check to make sure that the policy includes allow rules for cupsd_t for all of the types on the path to that directory. You can also build a policy with _no_ dontaudit rules via make clean enableaudit load, but this will generate a _lot_ of audit messages, many of which are not of interest (and then a subsequent make clean load will fix it back up again). -- Stephen Smalley National Security Agency From netllama at gmail.com Thu Jan 26 17:08:25 2006 From: netllama at gmail.com (Lonni J Friedman) Date: Thu, 26 Jan 2006 09:08:25 -0800 Subject: 3rd party shared objects won't work without disabling SELinux In-Reply-To: <1138282544.13075.97.camel@moss-spartans.epoch.ncsc.mil> References: <7c1574a90601251616v6c99efdet180973036aa977de@mail.gmail.com> <1138282544.13075.97.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <7c1574a90601260908m5f00bbe5s1328ded985d6ce82@mail.gmail.com> On 1/26/06, Stephen Smalley wrote: > On Wed, 2006-01-25 at 16:16 -0800, Lonni J Friedman wrote: > > Hello, > > I'm working on an application that requires 3rd party (outside of what > > ships with FC) shared libraries. With FC4, I'm not having any > > problems. Up until just a few days ago, everything was working in > > FC5-test2 as well. > > > > However it seems that some update suddenly broke things in such a way > > that unless I completely disable SELinux, I cannot load/access the > > shared objects that I installed. When I attempt to do so, I get the > > following error: > > cannot enable executable stack as shared object requires: Permission denied > > > > Can someone point out what SELinux foo I might be missing here? > > For discussion of the same issue for another application and DSO, see: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178924 > and > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170187 > > Can you run 'execstack -c' on the shared object? If that succeeds, does well, yes & no. It seems to fix one problem, but then causes another. > the program then work? Also, check your /var/log/audit/audit.log for > any other AVC denials. Thanks, this gives me enough info to have a starting point to work on this further. I'll speak up if I have more questions/problems that I can't figure out. -Lonni From Valdis.Kletnieks at vt.edu Thu Jan 26 18:02:00 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 26 Jan 2006 13:02:00 -0500 Subject: rawhide selinux-policy-strict whoopsage... Message-ID: <200601261802.k0QI20ga016020@turing-police.cc.vt.edu> Ran yum, it tried to install selinux-policy-strict-2.2.5-1 and died a horrid death: Updating : selinux-policy-strict ####################### [13/24] libsepol.verify_module_requirements: Module acct's global requirements were not met: type/attribute sysadm_home_dir_t libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! libsepol.verify_module_requirements: Module alsa's global requirements were not met: type/attribute devlog_t libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! libsepol.verify_module_requirements: Module amanda's global requirements were not met: type/attribute sysadm_home_dir_t libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! .... (skipping scads of similar errors..) libsepol.verify_module_requirements: Module xserver's global requirements were not met: type/attribute logfile libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! libsepol.verify_module_requirements: Module zebra's global requirements were not met: type/attribute direct_init libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! Running strict/permissive. Any suggestions? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From russell at coker.com.au Thu Jan 26 10:40:36 2006 From: russell at coker.com.au (Russell Coker) Date: Thu, 26 Jan 2006 21:40:36 +1100 Subject: 3rd party shared objects won't work without disabling SELinux In-Reply-To: <7c1574a90601251616v6c99efdet180973036aa977de@mail.gmail.com> References: <7c1574a90601251616v6c99efdet180973036aa977de@mail.gmail.com> Message-ID: <200601262140.43459.russell@coker.com.au> On Thursday 26 January 2006 11:16, Lonni J Friedman wrote: > However it seems that some update suddenly broke things in such a way > that unless I completely disable SELinux, I cannot load/access the > shared objects that I installed. When I attempt to do so, I get the > following error: > cannot enable executable stack as shared object requires: Permission denied http://www.crypt.gen.nz/selinux/faq.html The FAQ has an entry on this which is better than I can offer right now. Let me know if you still need more information after reading it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From dwalsh at redhat.com Fri Jan 27 07:10:01 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 27 Jan 2006 02:10:01 -0500 Subject: rawhide selinux-policy-strict whoopsage... In-Reply-To: <200601261802.k0QI20ga016020@turing-police.cc.vt.edu> References: <200601261802.k0QI20ga016020@turing-police.cc.vt.edu> Message-ID: <43D9C749.5020508@redhat.com> Valdis.Kletnieks at vt.edu wrote: > Ran yum, it tried to install selinux-policy-strict-2.2.5-1 and died a horrid death: > > > Updating : selinux-policy-strict ####################### [13/24] > libsepol.verify_module_requirements: Module acct's global requirements were not met: type/attribute sysadm_home_dir_t > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! > libsepol.verify_module_requirements: Module alsa's global requirements were not met: type/attribute devlog_t > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! > libsepol.verify_module_requirements: Module amanda's global requirements were not met: type/attribute sysadm_home_dir_t > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! > .... (skipping scads of similar errors..) > libsepol.verify_module_requirements: Module xserver's global requirements were not met: type/attribute logfile > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! > libsepol.verify_module_requirements: Module zebra's global requirements were not met: type/attribute direct_init > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! > > Running strict/permissive. Any suggestions? > > Yes stict is still very much a work in process. Basically we need major fixup on modules.conf to get it working properly. Hopefully we will have it fixed soon. I am mainly focused on MLS and Targeted though. > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From SeLinux at Compucenter.org Fri Jan 27 10:36:18 2006 From: SeLinux at Compucenter.org (G Jahchan) Date: Fri, 27 Jan 2006 12:36:18 +0200 Subject: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16 Message-ID: I have been desperately trying to get selinux strict policy to work on my laptop to no avail. I have been using a strict policy in enforcing mode for a long time, but since I upgraded to the kernel / selinux versions listed below, when in enforcing mode, the policy causes authentication to fail from the console (my default runlevel is 3). Even though I have the following statements in my custom.te under /etc/selinux/strict/src/policy/domains/misc/ allow kernel_t sysadm_t:process transition; allow kernel_t sysadm_tty_device_t:chr_file { relabelfrom relabelto }; allow sysadm_t sysadm_t:process transition; I keep getting corresponding 'avc: denied' events in the audit log. Kernel auditing is enabled at boot time (audit=1 kernel switch) and the audit daemon is set to run at boot time. I am using: kernel-2.6.14-1.1653_FC4 selinux-policy-strict-sources-1.27.1-2.16 How can I go about fixing this issue? From sds at tycho.nsa.gov Fri Jan 27 12:33:54 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 27 Jan 2006 07:33:54 -0500 Subject: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16 In-Reply-To: References: Message-ID: <1138365234.13075.243.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-01-27 at 12:36 +0200, G Jahchan wrote: > I have been desperately trying to get selinux strict policy to work on my > laptop to no avail. I have been using a strict policy in enforcing mode for a > long time, but since I upgraded to the kernel / selinux versions listed below, > when in enforcing mode, the policy causes authentication to fail from the > console (my default runlevel is 3). > > Even though I have the following statements in my custom.te under > /etc/selinux/strict/src/policy/domains/misc/ > > allow kernel_t sysadm_t:process transition; > allow kernel_t sysadm_tty_device_t:chr_file { relabelfrom relabelto }; > allow sysadm_t sysadm_t:process transition; > > I keep getting corresponding 'avc: denied' events in the audit log. These rules shouldn't be necessary, so they imply a more fundamental problem. They suggest that your login program is still running in kernel_t rather than local_login_t. In turn, this suggests that the initial transition from kernel_t to init_t upon executing /sbin/init did not occur. What does ls -Z /sbin/init show? What does '/usr/sbin/sestatus -v | grep -v active' show? As a side note, avc denials can be caused by other components of the policy beyond the TE rules, and the above permissions are likely being (correctly) denied by the role-based restrictions and user-based restrictions. Normally, kernel_t doesn't need to be able to transition to a user security context since kernel_t is only for the initial kernel task and other kernel threads. audit2why(8) will try to tell you why a given avc denial occurred. -- Stephen Smalley National Security Agency From bruce.ecroyd at gmail.com Fri Jan 27 13:16:31 2006 From: bruce.ecroyd at gmail.com (Bruce Ecroyd) Date: Fri, 27 Jan 2006 08:16:31 -0500 Subject: Resend: Error sending status request (Operation not permitted) Message-ID: I recently switched from FC4 targeted (enforcing) to strict (permissive) using selinux-policy-strict-1.27.1-2.16.noarch.rpm. I did a touch /.autorelabel before rebooting. I see this: [bruce at BorgCube ~]$ su - Password: Error sending status request (Operation not permitted) [root at BorgCube ~]# The last part of the /var/log/audit/audit.log shows: type=SYSCALL msg=audit(1138247001.111:13162965): arch=40000003 syscall=5 success=yes exit=3 a0=866125b a1=c2 a2=180 a3=3a8083 items=1 pid=8250 auid=4294967295 uid=501 gid=100 euid=0 suid=0 fsuid=0 egid=100 sgid=100 fsgid=100 comm="su" exe="/bin/su" type=AVC msg=audit(1138247001.111:13162965): avc: denied { create } for pid=8250 comm="su" name=.xauthVpNVFy scontext=user_u:user_r:user_t tcontext=user_u:object_r:sysadm_home_dir_t tclass=file type=AVC msg=audit(1138247001.111:13162965): avc: denied { add_name } for pid=8250 comm="su" name=.xauthVpNVFy scontext=user_u:user_r:user_t tcontext=root:object_r:sysadm_home_dir_t tclass=dir type=AVC msg=audit(1138247001.111:13162965): avc: denied { write } for pid=8250 comm="su" name=root dev=dm-0 ino=11392129 scontext=user_u:user_r:user_t tcontext=root:object_r:sysadm_home_dir_t tclass=dir type=SYSCALL msg=audit(1138247001.111:13162967): arch=40000003 syscall=207 success=yes exit=0 a0=3 a1=0 a2=0 a3=0 items=0 pid=8250 auid=4294967295 uid=501 gid=100 euid=0 suid=0 fsuid=0 egid=100 sgid=100 fsgid=100 comm="su" exe="/bin/su" type=AVC msg=audit(1138247001.111:13162967): avc: denied { setattr } for pid=8250 comm="su" name=.xauthVpNVFy dev=dm-0 ino=11392172 scontext=user_u:user_r:user_t tcontext=user_u:object_r:sysadm_home_dir_t tclass=file type=USER msg=audit(1138247001.325:13165423): user pid=8250 uid=501 auid=4294967295 msg='PAM session open: user=root exe=/bin/su (hostname=?, addr=?, terminal=pts/2 result=Success)' Any ideas? If I change to strict, enforcing, will this prevent me from su to root? Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at tycho.nsa.gov Fri Jan 27 14:08:48 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 27 Jan 2006 09:08:48 -0500 Subject: Resend: Error sending status request (Operation not permitted) In-Reply-To: References: Message-ID: <1138370928.13075.303.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-01-27 at 08:16 -0500, Bruce Ecroyd wrote: > I recently switched from FC4 targeted (enforcing) to strict > (permissive) using selinux-policy-strict-1.27.1-2.16.noarch.rpm. > I did a touch /.autorelabel before rebooting. Please turn off HTML mail in your mail client; it isn't desirable for public mailing lists in particular. > I see this: > [bruce at BorgCube ~]$ su - > Password: > Error sending status request (Operation not permitted) > [root at BorgCube ~]# > > The last part of the /var/log/audit/audit.log shows: > type=SYSCALL msg=audit(1138247001.111:13162965): arch=40000003 > syscall=5 success=yes exit=3 a0=866125b a1=c2 a2=180 a3=3a8083 items=1 > pid=8250 auid=4294967295 uid=501 gid=100 euid=0 suid=0 fsuid=0 > egid=100 sgid=100 fsgid=100 comm="su" exe="/bin/su" > type=AVC msg=audit(1138247001.111:13162965): avc: denied { create } > for pid=8250 comm="su" name=.xauthVpNVFy > scontext=user_u:user_r:user_t > tcontext=user_u:object_r:sysadm_home_dir_t tclass=file Under strict policy, users can only use 'su' if they are assigned the staff_r role. Unless you turn on the user_canbe_sysadm tunable and rebuild the policy. So you need to authorize your username for staff_r. Under FC4, you can do this via: vi /etc/selinux/strict/users/local.users /usr/sbin/load_policy /etc/selinux/strict/policy/policy.19 /usr/sbin/genhomedircon /sbin/restorecon -R /home/ Alternatively, you can install selinux-policy-strict-sources, cd /etc/selinux/strict/src/policy, and edit its users file, followed by a make load and the above restorecon. Alterntively, you can install selinux-policy-strict-sources, cd /etc/selinux/strict/src/policy, and edit the tunables/tunable.tun file, enable the user_canbe_sysadm tunable (by removing the dnl prefix), followed by a make load. In which case you (and any other user_r user) can use su (still requiring them to know the root password). But that isn't as secure. As a heads up, note that this approach will be obsoleted in FC5. In FC5, you can map Linux users to predefined SELinux pseudo-users (like staff_u) using the semanage tool and not need to rebuild or reload policy (although you still have to label the user's home directory). > If I change to strict, enforcing, will this prevent me from su to > root? Yes, it should, since you weren't authorized for staff_r. -- Stephen Smalley National Security Agency From SeLinux at Compucenter.org Fri Jan 27 15:49:36 2006 From: SeLinux at Compucenter.org (G Jahchan) Date: Fri, 27 Jan 2006 17:49:36 +0200 Subject: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16 In-Reply-To: <1138365234.13075.243.camel@moss-spartans.epoch.ncsc.mil> Message-ID: ls -Z /sbin/init -rwxr-xr-x root root system_u:object_r:staff_home_t /sbin/init /usr/sbin/sestatus -v | grep -v active SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: permissive Policy version: 20 Policy from config file: strict Policy booleans: Process contexts: Current context: gjahchan:sysadm_r:sysadm_t Init context: system_u:system_r:kernel_t File contexts: Controlling term: gjahchan:object_r:devpts_t /etc/passwd system_u:object_r:staff_home_t /etc/shadow system_u:object_r:shadow_t /bin/bash system_u:object_r:staff_home_t /bin/login system_u:object_r:staff_home_t /bin/sh system_u:object_r:bin_t -> system_u:object_r:staff_home_t /sbin/agetty system_u:object_r:getty_exec_t /sbin/init system_u:object_r:staff_home_t /sbin/mingetty system_u:object_r:staff_home_t /usr/sbin/sshd system_u:object_r:staff_home_t /lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:shlib_t /lib/ld-linux.so.2 system_u:object_r:lib_t -> system_u:object_r The results of audit2why seem to indicate a mismatch between current in-memory boolean settings vs. permanent ones. It sounds like I have a boolean problem. Now I remember, while booting, a boolean error message very quickly scrolls, I never managed to read it, and it is not logged in any of the logs (boot, dmesg, or messages). The audit daemon would not have started at this stage. Any idea where the error is logged if at all, or how to force a manual generation of the event post startup? -----Original Message----- From: Stephen Smalley [mailto:sds at tycho.nsa.gov] Sent: Friday, January 27, 2006 14:34 To: G Jahchan Cc: Fedora SE Linux List Subject: Re: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16 On Fri, 2006-01-27 at 12:36 +0200, G Jahchan wrote: > I have been desperately trying to get selinux strict policy to work on my > laptop to no avail. I have been using a strict policy in enforcing mode for a > long time, but since I upgraded to the kernel / selinux versions listed below, > when in enforcing mode, the policy causes authentication to fail from the > console (my default runlevel is 3). > > Even though I have the following statements in my custom.te under > /etc/selinux/strict/src/policy/domains/misc/ > > allow kernel_t sysadm_t:process transition; > allow kernel_t sysadm_tty_device_t:chr_file { relabelfrom relabelto }; > allow sysadm_t sysadm_t:process transition; > > I keep getting corresponding 'avc: denied' events in the audit log. These rules shouldn't be necessary, so they imply a more fundamental problem. They suggest that your login program is still running in kernel_t rather than local_login_t. In turn, this suggests that the initial transition from kernel_t to init_t upon executing /sbin/init did not occur. What does ls -Z /sbin/init show? What does '/usr/sbin/sestatus -v | grep -v active' show? As a side note, avc denials can be caused by other components of the policy beyond the TE rules, and the above permissions are likely being (correctly) denied by the role-based restrictions and user-based restrictions. Normally, kernel_t doesn't need to be able to transition to a user security context since kernel_t is only for the initial kernel task and other kernel threads. audit2why(8) will try to tell you why a given avc denial occurred. -- Stephen Smalley National Security Agency From steve at atc-nycorp.com Fri Jan 27 16:29:40 2006 From: steve at atc-nycorp.com (Steve Brueckner) Date: Fri, 27 Jan 2006 11:29:40 -0500 Subject: avc denied gone after reboot Message-ID: <60D45469A1AAD311A04C009027B6BF6805D37DBE@server20.inside.oracorp.com> I'm creating an SELinux-enabled Xen VM on FC4. I create the file system for the VM by copying the filesystem from the underlying host. For the very first boot of the VM, I have it /.auotrelabel. However, when I then try to install an rpm inside the VM I get an avc denied, even though I can install the same rpm on the underlying host just fine. Even stranger, if I reboot the VM once, I then have no problem installing the rpm inside of it. So there are two oddities: 1 - why does the rpm install fine on the host but not in the VM that clones the host's file system? 2 - why does the rpm install correctly after a reboot, but not after the initial boot? Aside from upgrading my policy, how can I track down the problem here? Here are some details: # rpm -ivh jre: error: unpacking of archive failed on file /usr/java/jre1.5.0_01/CHANGES: cpio: lsetfilecon failed - Permission denied /var/log/audit/audit.log: type=AVC msg=audit(1138316170.719:32): avc: denied { relabelto } for pid=1706 comm="rpm" name="CHANGES" dev=hda1 ino=16578 scontext=root:system_r:kernel_t tcontext=system_u:object_r:usr_t tclass=file # rpm -qa | grep selinux: libselinux-devel-1.23.10-2 libselinux-1.23.10-2 selinux-policy-targeted-sources-1.27.1-2.16 selinux-policy-targeted-1.27.1-2.16 I haven't altered the policy sources (yet). Both host and VM are in enforcing mode. Thanks, - Steve Stephen Brueckner, ATC-NY From nicolas.mailhot at laposte.net Fri Jan 27 16:51:53 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 27 Jan 2006 17:51:53 +0100 (CET) Subject: avc denied gone after reboot In-Reply-To: <60D45469A1AAD311A04C009027B6BF6805D37DBE@server20.inside.oracorp.com> References: <60D45469A1AAD311A04C009027B6BF6805D37DBE@server20.inside.oracorp.com> Message-ID: <41821.192.54.193.25.1138380713.squirrel@rousalka.dyndns.org> Le Ven 27 janvier 2006 17:29, Steve Brueckner a ?crit : > I'm creating an SELinux-enabled Xen VM on FC4. I create the file system > for > the VM by copying the filesystem from the underlying host. For the very > first boot of the VM, I have it /.auotrelabel. However, when I then try > to > install an rpm inside the VM I get an avc denied, even though I can > install > the same rpm on the underlying host just fine. Even stranger, if I reboot > the VM once, I then have no problem installing the rpm inside of it. I strongly suspect autorelabel is WAY BROKEN right now, meaning in many cases after a relabel the system should reboot but doesn't (ie the new policy is not effective after the relabeling before a reboot has occurred, in fact I wonder what exact policy mashup applies till then) This could be related to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178125 I haven't have the time to do a complete investigation I may be totally wrong but that's how things look like from there -- Nicolas Mailhot From latten at austin.ibm.com Fri Jan 27 17:06:54 2006 From: latten at austin.ibm.com (Joy Latten) Date: Fri, 27 Jan 2006 11:06:54 -0600 Subject: macros in old policy Message-ID: <1138381614.29650.23.camel@faith.austin.ibm.com> I am converting the selinux testsuite policy to reference policy. The old test policy used the macros, can_setcon, can_setexec, can_setfscreate. These macros are not existent in the source for current refpolicy. Will these macros be included in refpolicy or obsolete, or do I write them myself in the test module, or do they map to something else now? Just wondering what is the correct thing to do? Regards, Joy Latten From sds at tycho.nsa.gov Fri Jan 27 16:51:51 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 27 Jan 2006 11:51:51 -0500 Subject: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16 In-Reply-To: <1138380247.13075.325.camel@moss-spartans.epoch.ncsc.mil> References: <1138380247.13075.325.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1138380711.13075.333.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-01-27 at 11:44 -0500, Stephen Smalley wrote: > On Fri, 2006-01-27 at 17:49 +0200, G Jahchan wrote: > > ls -Z /sbin/init > > -rwxr-xr-x root root system_u:object_r:staff_home_t /sbin/init > > That's your problem - your filesystem is incorrectly labeled. Don't > know how your /sbin/init program ended up with the type of a staff home > directory; it should have init_exec_t. > > /sbin/restorecon -nv /sbin/init Oops, that should just be: /sbin/restorecon -v /sbin/init The -n prevents it from actually relabeling, so -nv is useful when you want to see what it would do without actually applying the change, but in this case, we do want to make the change as well as see exactly what it does (hence -v for verbose). > If that correctly relabels to init_exec_t, then proceed to do a full > relabel, i.e. touch /.autorelabel and reboot or pass 'autorelabel' on > the kernel command line. Or shut down to single-user and run 'fixfiles > relabel'. All variations on the same theme... Given the extent of labeling errors reported by sestatus, you definitely want to do a full relabel, after verifying that at least the above manual restorecon of init is working properly. If that restorecon doesn't work properly, then possibly your file_contexts.homedirs is not being correctly generated by genhomedircon. You don't happen to have users with home directories of /sbin and /bin, do you? -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri Jan 27 16:44:07 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 27 Jan 2006 11:44:07 -0500 Subject: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16 In-Reply-To: References: Message-ID: <1138380247.13075.325.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-01-27 at 17:49 +0200, G Jahchan wrote: > ls -Z /sbin/init > -rwxr-xr-x root root system_u:object_r:staff_home_t /sbin/init That's your problem - your filesystem is incorrectly labeled. Don't know how your /sbin/init program ended up with the type of a staff home directory; it should have init_exec_t. /sbin/restorecon -nv /sbin/init If that correctly relabels to init_exec_t, then proceed to do a full relabel, i.e. touch /.autorelabel and reboot or pass 'autorelabel' on the kernel command line. Or shut down to single-user and run 'fixfiles relabel'. All variations on the same theme... > /etc/passwd system_u:object_r:staff_home_t Should be etc_t. > /bin/bash system_u:object_r:staff_home_t shell_exec_t > /bin/login system_u:object_r:staff_home_t login_exec_t > /sbin/init system_u:object_r:staff_home_t init_exec_t > /sbin/mingetty system_u:object_r:staff_home_t getty_exec_t > /usr/sbin/sshd system_u:object_r:staff_home_t sshd_exec_t > The results of audit2why seem to indicate a mismatch between current in-memory > boolean settings vs. permanent ones. No, just a filesystem labeling problem. audit2why can't determine that; it just diagnoses policy problems. -- Stephen Smalley National Security Agency From Valdis.Kletnieks at vt.edu Fri Jan 27 19:18:42 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Jan 2006 14:18:42 -0500 Subject: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16 In-Reply-To: Your message of "Fri, 27 Jan 2006 11:44:07 EST." <1138380247.13075.325.camel@moss-spartans.epoch.ncsc.mil> References: <1138380247.13075.325.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200601271918.k0RJIg8O025089@turing-police.cc.vt.edu> On Fri, 27 Jan 2006 11:44:07 EST, Stephen Smalley said: > On Fri, 2006-01-27 at 17:49 +0200, G Jahchan wrote: > > ls -Z /sbin/init > > -rwxr-xr-x root root system_u:object_r:staff_home_t /sbin/init > > That's your problem - your filesystem is incorrectly labeled. Don't > know how your /sbin/init program ended up with the type of a staff home > directory; it should have init_exec_t. It's probably related to the strict policy whoopsage I reported - the system would end up with only some 10% of the policy modules in place, and a restorecon wouldn't include the *.fc rules for the missing modules - so some less-restrictive rule would set the context (I ended up with almost everything as default_t, but I could see how staff_home_t might happen too...) At one point, every single process on my laptop was running in kernel_t, because the various init_t and similar types weren't defined, nor were the transitions for them. Good thing I'm running in permissive. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From sds at tycho.nsa.gov Fri Jan 27 19:29:22 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 27 Jan 2006 14:29:22 -0500 Subject: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16 In-Reply-To: <200601271918.k0RJIg8O025089@turing-police.cc.vt.edu> References: <1138380247.13075.325.camel@moss-spartans.epoch.ncsc.mil> <200601271918.k0RJIg8O025089@turing-police.cc.vt.edu> Message-ID: <1138390162.13075.373.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-01-27 at 14:18 -0500, Valdis.Kletnieks at vt.edu wrote: > On Fri, 27 Jan 2006 11:44:07 EST, Stephen Smalley said: > > On Fri, 2006-01-27 at 17:49 +0200, G Jahchan wrote: > > > ls -Z /sbin/init > > > -rwxr-xr-x root root system_u:object_r:staff_home_t /sbin/init > > > > That's your problem - your filesystem is incorrectly labeled. Don't > > know how your /sbin/init program ended up with the type of a staff home > > directory; it should have init_exec_t. > > It's probably related to the strict policy whoopsage I reported - the system > would end up with only some 10% of the policy modules in place, and a restorecon > wouldn't include the *.fc rules for the missing modules - so some less-restrictive > rule would set the context (I ended up with almost everything as default_t, > but I could see how staff_home_t might happen too...) > > At one point, every single process on my laptop was running in kernel_t, because > the various init_t and similar types weren't defined, nor were the transitions for > them. Good thing I'm running in permissive. ;) Except that his message indicated that he is running FC4, not rawhide (look at his kernel and policy versions). -- Stephen Smalley National Security Agency From gokhan.celik at gmail.com Fri Jan 27 20:01:52 2006 From: gokhan.celik at gmail.com (=?ISO-8859-9?Q?G=F6khan_Fazl=FD_=C7elik?=) Date: Fri, 27 Jan 2006 22:01:52 +0200 Subject: need help - new hard disk, messed up but uneditable fstab file Message-ID: <38c263210601271201i250edea1s76df6794e2c49346@mail.gmail.com> Hi, I am looking for an answer to the trouble I have faced, any help will be appreciated. I have added a secondary hdd and edited /etc/fstab file, it seems it is messed up. Selinux requires root password and this file remains read-only against all the efforts I have tried. chmod +w, or from "vi :x!" doesnot work and I am stuck at the boot stage.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at tycho.nsa.gov Fri Jan 27 20:25:17 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 27 Jan 2006 15:25:17 -0500 Subject: need help - new hard disk, messed up but uneditable fstab file In-Reply-To: <38c263210601271201i250edea1s76df6794e2c49346@mail.gmail.com> References: <38c263210601271201i250edea1s76df6794e2c49346@mail.gmail.com> Message-ID: <1138393517.13075.397.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-01-27 at 22:01 +0200, G?khan Fazl? ?elik wrote: > Hi, > I am looking for an answer to the trouble I have faced, any help will > be appreciated. > I have added a secondary hdd and edited /etc/fstab file, it seems it > is messed up. Selinux requires root password and this file remains > read-only against all the efforts I have tried. > chmod +w, > or from "vi :x!" doesnot work and I am stuck at the boot stage.. If it is truly selinux-related, you can always boot with enforcing=0 on the kernel command line (to disable enforcement of permission checks by SELinux) or further you can boot with selinux=0 on the kernel command line (to completely disable SELinux at boot). But I'm not clear that it is anything SELinux-related from your description. -- Stephen Smalley National Security Agency From m3freak at rogers.com Fri Jan 27 21:42:13 2006 From: m3freak at rogers.com (Kanwar Ranbir Sandhu) Date: Fri, 27 Jan 2006 16:42:13 -0500 Subject: su, context(selinux?) 2nd prompt In-Reply-To: <43D7B02E.7070004@redhat.com> References: <43D4FAAF.6020108@redhat.com> <43D7B02E.7070004@redhat.com> Message-ID: <1138398133.10271.12.camel@krs> On Wed, 2006-25-01 at 12:06 -0500, Daniel J Walsh wrote: > >> Remove multiple from the pam file. > >> > > > > editing /etc/pam.d/su, changing > > session required /lib/security/$ISA/pam_selinux.so open multiple > > to > > session required /lib/security/$ISA/pam_selinux.so open > > > > Did the trick, thanks Dan! > > > > # rpm -q -f /etc/pam.d/su > > coreutils-5.2.1-31.2 > > > > > You can actually remove the pam_selinux.so lines from the su file > altogether. We have done this for FC5 and it works > fine. In strict or MLS Policy you will be required to run newrole but > in targeted everything should just work. I'm seeing the same behaviour with telnetd. I had to install it for a client that runs a text based app which Windows users telnet into (it's only open to the local network, and the app loads immediately after login). When a user logs in via telnet, the same question appears. I told my client to just accept the default answer, which is "no". Ideally, I'd like to remove the option all together. I assume it's possible to turn it off like it was for "su", but I'm not sure which file to edit. /etc/pam.d/login looks like the closest one, specifically this line: # pam_selinux.so open should be the last session rule session required pam_selinux.so multiple open I'm not sure though. Any tips? Regards, Ranbir -- Kanwar Ranbir Sandhu Linux 2.6.14-1.1656_FC4 i686 GNU/Linux 16:34:54 up 9:34, 5 users, load average: 0.06, 0.35, 0.43 From selinux at gmail.com Sat Jan 28 17:09:07 2006 From: selinux at gmail.com (Tom London) Date: Sat, 28 Jan 2006 09:09:07 -0800 Subject: error in today's rawhide update.... Message-ID: <4c4ba1530601280909l22d8320dy2106d098ad44343c@mail.gmail.com> Running targeted/enforcing. Updating today via yum (updating from selinux-policy-targeted-2.2.6-2 to selinux-policy-targeted-2.2.8-1): Updating : selinux-policy-targeted ####################### [33/92] Traceback (most recent call last): File "/usr/sbin/genhomedircon", line 364, in ? selconf.write() File "/usr/sbin/genhomedircon", line 325, in write fd.write(self.genoutput()) File "/usr/sbin/genhomedircon", line 316, in genoutput ret += self.genHomeDirContext() File "/usr/sbin/genhomedircon", line 265, in genHomeDirContext users = self.getUsers() File "/usr/sbin/genhomedircon", line 210, in getUsers (status, list, lsize) = semanage_seuser_list(self.semanageHandle) NameError: global name 'semanage_seuser_list' is not defined libsemanage.semanage_install_sandbox: genhomedircon returned error code 1. /sbin/restorecon reset /usr/bin/rhgb context system_u:object_r:bin_t->system_u:object_r:xdm_exec_t Updating : NetworkManager-gnome ####################### [34/92] Nothing obvious in /var/log/messages or in /var/log/audit/audit.log -- Tom London From selinux at gmail.com Sat Jan 28 17:58:34 2006 From: selinux at gmail.com (Tom London) Date: Sat, 28 Jan 2006 09:58:34 -0800 Subject: NetworkManager in today's rawhide.... Message-ID: <4c4ba1530601280958s5de099b5v373dd997bef10cd@mail.gmail.com> NetworkManager is now in /usr/sbin, so it is not getting labeled as NetworkManager_exec_t. After doing a 'chcon -t NetworkManager_exec_t /usr/sbin/NetworkManager': ---- type=SOCKETCALL msg=audit(01/28/2006 09:50:36.513:61) : nargs=3 a0=10 a1=b74f40f4 a2=0 type=SOCKADDR msg=audit(01/28/2006 09:50:36.513:61) : saddr=netlink pid:0 type=SYSCALL msg=audit(01/28/2006 09:50:36.513:61) : arch=i386 syscall=socketcall(sendmsg) success=yes exit=32 a0=10 a1=b74f4070 a2=249268 a3=0 items=0 pid=3122 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=NetworkManager exe=/usr/sbin/NetworkManager type=AVC msg=audit(01/28/2006 09:50:36.513:61) : avc: denied { nlmsg_write } for pid=3122 comm=NetworkManager scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:NetworkManager_t:s0 tclass=netlink_route_socket -- Tom London From ivg2 at cornell.edu Sat Jan 28 19:24:22 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sat, 28 Jan 2006 12:24:22 -0700 Subject: error in today's rawhide update.... In-Reply-To: <4c4ba1530601280909l22d8320dy2106d098ad44343c@mail.gmail.com> References: <4c4ba1530601280909l22d8320dy2106d098ad44343c@mail.gmail.com> Message-ID: <43DBC4E6.8070907@cornell.edu> > Updating : selinux-policy-targeted ####################### [33/92] > Traceback (most recent call last): > File "/usr/sbin/genhomedircon", line 364, in ? > selconf.write() > File "/usr/sbin/genhomedircon", line 325, in write > fd.write(self.genoutput()) > File "/usr/sbin/genhomedircon", line 316, in genoutput > ret += self.genHomeDirContext() > File "/usr/sbin/genhomedircon", line 265, in genHomeDirContext > users = self.getUsers() > File "/usr/sbin/genhomedircon", line 210, in getUsers > (status, list, lsize) = semanage_seuser_list(self.semanageHandle) > NameError: global name 'semanage_seuser_list' is not defined > libsemanage.semanage_install_sandbox: genhomedircon returned error code 1. Out-of-sync update - libsemanage was updated, but policycoreutils was not. I'm sure it will be fixed soon. The above is the result of an API change. The major number was not increased, because of upstream policy to treat this API as unstable (and subject to change) until FC5 is released. From dwalsh at redhat.com Sat Jan 28 21:23:06 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 28 Jan 2006 16:23:06 -0500 Subject: error in today's rawhide update.... In-Reply-To: <43DBC4E6.8070907@cornell.edu> References: <4c4ba1530601280909l22d8320dy2106d098ad44343c@mail.gmail.com> <43DBC4E6.8070907@cornell.edu> Message-ID: <43DBE0BA.9070101@redhat.com> Ivan Gyurdiev wrote: > >> Updating : selinux-policy-targeted ####################### >> [33/92] >> Traceback (most recent call last): >> File "/usr/sbin/genhomedircon", line 364, in ? >> selconf.write() >> File "/usr/sbin/genhomedircon", line 325, in write >> fd.write(self.genoutput()) >> File "/usr/sbin/genhomedircon", line 316, in genoutput >> ret += self.genHomeDirContext() >> File "/usr/sbin/genhomedircon", line 265, in genHomeDirContext >> users = self.getUsers() >> File "/usr/sbin/genhomedircon", line 210, in getUsers >> (status, list, lsize) = semanage_seuser_list(self.semanageHandle) >> NameError: global name 'semanage_seuser_list' is not defined >> libsemanage.semanage_install_sandbox: genhomedircon returned error >> code 1. > Out-of-sync update - libsemanage was updated, but policycoreutils was > not. I'm sure it will be fixed soon. The above is the result of an API > change. The major number was not increased, because of upstream policy > to treat this API as unstable (and subject to change) until FC5 is > released. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Yes I updated both at last night but one made it into rawhide while the other missed the cut-off. Looks like a "race" condition. :^( It will be in tonights rawhide. Dan From lists at ebourne.me.uk Sat Jan 28 22:21:00 2006 From: lists at ebourne.me.uk (Martin Ebourne) Date: Sat, 28 Jan 2006 22:21:00 +0000 Subject: Nagios nrpe and sudo Message-ID: <1138486860.11412.21.camel@avenin.ebourne.me.uk> Hi, I'm getting AVC denied with a nagios nrpe script which needs to sudo. The script works fine without selinux. I'm on FC4. nrpe is the remote execution feature in nagios. It runs under xinetd and accepts incoming commands. It then runs scripts to fetch results. My script to get harddisk smart attributes looks like so: ========== #!/bin/sh device="$1" attribute="$2" #id sudo /usr/sbin/smartctl -A $device | perl -ne 'm{^\s*\Q'"$attribute"'\E \s} && split && print "$_[9]"' ========== During execution of the script id returns: uid=173(nagios) gid=173(nagios) context=system_u:system_r:inetd_t But I get this avc denial: type=AVC msg=audit(1138482709.249:31780): avc: denied { entrypoint } for pid=11537 comm="sudo" name="sesh" dev=dm-0 ino=442643 scontext=root:system_r:amanda_t tcontext=system_u:object_r:shell_exec_t tclass=file Seems reasonable. There don't seem to be any booleans for nrpe but there is inetd_child_disable_trans. With that set id gives: uid=173(nagios) gid=173(nagios) context=root:system_r:inetd_t But I get the same denial: type=AVC msg=audit(1138485617.391:32037): avc: denied { entrypoint } for pid=14228 comm="sudo" name="sesh" dev=dm-0 ino=442643 scontext=root:system_r:amanda_t tcontext=system_u:object_r:shell_exec_t tclass=file I've no idea what amanda_t has got to do with any of this. Am I missing something obvious? It seems to be running in the new context, but still be protected. The inetd_child_disable_trans is described in system-config-securitylevel as "Disable SELinux protection for inetd child daemons", which is what I seem to need. I also notice that the current policy has some nrpe stuff in it, but that doesn't ever seem to take effect. Is this incomplete, or broken? Cheers, Martin. From jonathan.underwood at gmail.com Sun Jan 29 16:03:13 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 29 Jan 2006 16:03:13 +0000 Subject: SElinux and firestarter Message-ID: <645d17210601290803u3a931d1fg@mail.gmail.com> Hi, There appears to be issues with SElinux and the firestarter package available from fedora-extras. I have attached the errors from /var/log/messages upon boot to this email. I suspect it may be related to either dhcpd or kernel module loading upon boot, but I'm rather clueless about SElinux. If someone could give me some pointers on how to proceed with debugging this it would be really appreciated. I have reported the bug here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179248 This is with kernel 2.6.14-1.1656_FC4, libselinux-1.23.10-2, selinux-policy-targeted-1.27.1-2.16. I realize that I have probably not given enough information to debug this, but I am not sure what else would be useful. Many thanks, Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: messages Type: application/octet-stream Size: 12085 bytes Desc: not available URL: From odyyudah at gmail.com Mon Jan 30 01:16:00 2006 From: odyyudah at gmail.com (ody quraviharto) Date: Mon, 30 Jan 2006 08:16:00 +0700 Subject: does selinux work with non-fedora package ? Message-ID: <5a3d805c0601291716y38c8613eo6dabe1967e8d1178@mail.gmail.com> hi all, I am a Fedora newbie interesting in selinux. here are some questions 1. does selinux work well with reiserfs filesystem ? 2. does selinux work well with postgresql rpm packages I downloaded from postgresql site ? thx very much From justin at jdjlab.com Mon Jan 30 03:37:34 2006 From: justin at jdjlab.com (Justin Willmert) Date: Sun, 29 Jan 2006 21:37:34 -0600 Subject: Spamassassin emails have wrong perms -- CC'ed to selinux list In-Reply-To: <43DD5D06.5020004@jdjlab.com> References: <43DD5D06.5020004@jdjlab.com> Message-ID: <43DD89FE.8000003@jdjlab.com> Justin Willmert wrote: > I am hoping somebody can help me solve a problem I am having with > procmail and spamassassin (specifically spamd). When spamassassin has > marked a message as spam, it gets sorted to a Junk folder, but the > problem is that it is owned by root:mail when it should be owned by > the user. When this happens, dovecot will not serve the email to the > user. I sort other emails into folders with simple matching rules and > those work fine. Spamassassin is the only rule that is piped out to a > program. > > Here is the relevant portion my procmailrc file: > > DROPPRIV=yes # Make this run as a normal user. If > you need > # root privileges for something, do > it before > # this line. > # Send mail through spamassassin > :0fw > | spamc -u $LOGNAME > > # Now that we've tagged the spam, put in the appropriate folder > :0 > * ^X-Spam-Status: Yes > .Junk/ > > I've tried taking the -u $LOGNAME portion out too and that doesn't > work. Following is a maillog sample. > > Jan 29 17:47:11 netserv sendmail[19847]: k0TNlAig019847: Milter add: > header: X-Virus-Scanned: ClamAV 0.88/1257/Sun Jan 29 09:15:47 2006 > on mydomain.com > Jan 29 17:47:11 netserv sendmail[19847]: k0TNlAig019847: Milter add: > header: X-Virus-Status: Clean > Jan 29 17:47:11 netserv spamd[19654]: connection from mydomain.com > [127.0.0.1] at port 57905 > Jan 29 17:47:11 netserv spamd[19654]: handle_user: unable to find > user 'justin'! > Jan 29 17:47:11 netserv spamd[19654]: Still running as root: user > not specified with -u, not found, or set to root. Fall back to > nobody. > Jan 29 17:47:11 netserv spamd[19654]: processing message > for justin:99. > Jan 29 17:47:11 netserv spamd[19654]: cannot write to > /etc/mail/bayes/bayes_journal, Bayes db update ignored: Permission > denied > Jan 29 17:47:13 netserv spamd[19654]: clean message (1.7/5.0) for > justin:99 in 1.5 seconds, 1076 bytes. > Jan 29 17:47:13 netserv spamd[19654]: result: . 1 - > BAYES_50,DNS_FROM_RFC_POST,MSGID_FROM_MTA_HEADER > > scantime=1.5,size=1076,mid=,bayes=0.499999999735837,autolearn=no > > Jan 29 17:47:13 netserv sendmail[19849]: k0TNlAig019847: > to=, delay=00:00:02, xdelay=00:00:02, > mailer=local, pri=30995, dsn=2.0.0, stat=Sent > > As you can see, I've also got a problem with not being able to access > the bayes_journal. I've put it in it's own directory and made them > owned by nobody:staff and still nothing. Anyway, here is my local.cf > file: > > # These values can be overridden by editing > ~/.spamassassin/user_prefs.cf > # (see spamassassin(1) for details) > > # How many hits before a message is considered spam. The lower the > number, the > # more sensitive it is. > required_hits 5 > > # Encapsulate spam in an attachment (0=No, 1=Yes in message/rfc822, > # 2=Yes in text/plain) > report_safe 0 > > # Text to prepend to subject of spam > rewrite_header Subject [SPAM] > > # Enable the Bayes System > use_bayes 1 > > # Enable Bayes auto-learning > bayes_auto_learn 1 > > # Mail using languages used in these country codes will not be > marked as being > # possibly spam in a foreign language. > ok_languages en > > I'd be happy to send along any other information you need. Thanks for > help in advance. > > Justin Willmert > I'm cc-ing this to the fedora-selinux-list. I think some of the problems may be applicable there. OK, after some more testing, when I disable SELinux, many of the errors go away. First of all, I get rid of the error message saying user can not be found and with it the 'still running as root' error. Second, it is able to access the bayes_journal file (as long as normal unix permissions are right, which I've figured out). So I guess the problem is an SELinux issue which I can't solve. I'd attach some avc error messages, but I can't seem to find any. I've looked in maillog, secure, and messages, but nothing. From ivg2 at cornell.edu Mon Jan 30 04:38:04 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 29 Jan 2006 21:38:04 -0700 Subject: Spamassassin emails have wrong perms -- CC'ed to selinux list In-Reply-To: <43DD89FE.8000003@jdjlab.com> References: <43DD5D06.5020004@jdjlab.com> <43DD89FE.8000003@jdjlab.com> Message-ID: <43DD982C.3010702@cornell.edu> > I'm cc-ing this to the fedora-selinux-list. I think some of the > problems may be applicable there. > > OK, after some more testing, when I disable SELinux, many of the > errors go away. First of all, I get rid of the error message saying > user can not be found and with it the 'still running as root' error. > Second, it is able to access the bayes_journal file (as long as normal > unix permissions are right, which I've figured out). So I guess the > problem is an SELinux issue which I can't solve. I'd attach some avc > error messages, but I can't seem to find any. I've looked in maillog, > secure, and messages, but nothing. Have you looked in the audit log, where all such messages are usually found ? /var/log/audit.log From justin at jdjlab.com Mon Jan 30 04:52:22 2006 From: justin at jdjlab.com (Justin Willmert) Date: Sun, 29 Jan 2006 22:52:22 -0600 Subject: Spamassassin emails have wrong perms -- CC'ed to selinux list In-Reply-To: <43DD982C.3010702@cornell.edu> References: <43DD5D06.5020004@jdjlab.com> <43DD89FE.8000003@jdjlab.com> <43DD982C.3010702@cornell.edu> Message-ID: <43DD9B86.9000406@jdjlab.com> Ivan Gyurdiev wrote: > >> I'm cc-ing this to the fedora-selinux-list. I think some of the >> problems may be applicable there. >> >> OK, after some more testing, when I disable SELinux, many of the >> errors go away. First of all, I get rid of the error message saying >> user can not be found and with it the 'still running as root' error. >> Second, it is able to access the bayes_journal file (as long as >> normal unix permissions are right, which I've figured out). So I >> guess the problem is an SELinux issue which I can't solve. I'd attach >> some avc error messages, but I can't seem to find any. I've looked in >> maillog, secure, and messages, but nothing. > Have you looked in the audit log, where all such messages are usually > found ? > /var/log/audit.log > Below is what showed up in audit/audit.log when I sent a message through spamassassin. I'm _*really*_ rusty on SELinux...it's the one thing I have to deal with quite often that I haven't been able to learn how to use...it's so foreign to me. I've never looked in audit.log before: the avc messages used to show up in messages, but now as far back as my logs go, I don't have a single avc message. This all looks like jibberish to me, so I need your guy's help. Thanks, Justin type=AVC msg=audit(1138596151.681:104174): avc: denied { name_connect } for pid=23796 comm="spamd" dest=389 scontext=root:system_r:spamd_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket type=SYSCALL msg=audit(1138596151.681:104174): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 items=0 pid=23796 auid=600 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl" type=SOCKADDR msg=audit(1138596151.681:104174): saddr=02000185C0A801940000000000000000 type=SOCKETCALL msg=audit(1138596151.681:104174): nargs=3 a0=7 a1=9b1fe80 a2=10 type=AVC msg=audit(1138596153.220:104175): avc: denied { name_connect } for pid=23796 comm="spamd" dest=389 scontext=root:system_r:spamd_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket type=SYSCALL msg=audit(1138596153.220:104175): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 items=0 pid=23796 auid=600 uid=0 gid=0 euid=99 suid=0 fsuid=99 egid=99 sgid=0 fsgid=99 comm="spamd" exe="/usr/bin/perl" type=SOCKADDR msg=audit(1138596153.220:104175): saddr=02000185C0A801940000000000000000 type=SOCKETCALL msg=audit(1138596153.220:104175): nargs=3 a0=7 a1=9b6a6f0 a2=10 type=AVC msg=audit(1138596160.388:104176): avc: denied { name_connect } for pid=23797 comm="spamd" dest=389 scontext=root:system_r:spamd_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket type=SYSCALL msg=audit(1138596160.388:104176): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 items=0 pid=23797 auid=600 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl" type=SOCKADDR msg=audit(1138596160.388:104176): saddr=02000185C0A801940000000000000000 type=SOCKETCALL msg=audit(1138596160.388:104176): nargs=3 a0=7 a1=9b20050 a2=10 type=AVC msg=audit(1138596164.032:104177): avc: denied { name_connect } for pid=23797 comm="spamd" dest=389 scontext=root:system_r:spamd_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket type=SYSCALL msg=audit(1138596164.032:104177): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 items=0 pid=23797 auid=600 uid=0 gid=0 euid=99 suid=0 fsuid=99 egid=99 sgid=0 fsgid=99 comm="spamd" exe="/usr/bin/perl" type=SOCKADDR msg=audit(1138596164.032:104177): saddr=02000185C0A801940000000000000000 type=SOCKETCALL msg=audit(1138596164.032:104177): nargs=3 a0=7 a1=9b84af0 a2=10 From paul at city-fan.org Mon Jan 30 07:53:19 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 30 Jan 2006 07:53:19 +0000 Subject: Spamassassin emails have wrong perms -- CC'ed to selinux list In-Reply-To: <43DD9B86.9000406@jdjlab.com> References: <43DD5D06.5020004@jdjlab.com> <43DD89FE.8000003@jdjlab.com> <43DD982C.3010702@cornell.edu> <43DD9B86.9000406@jdjlab.com> Message-ID: <1138607599.29207.35.camel@laurel.intra.city-fan.org> On Sun, 2006-01-29 at 22:52 -0600, Justin Willmert wrote: > Ivan Gyurdiev wrote: > > > >> I'm cc-ing this to the fedora-selinux-list. I think some of the > >> problems may be applicable there. > >> > >> OK, after some more testing, when I disable SELinux, many of the > >> errors go away. First of all, I get rid of the error message saying > >> user can not be found and with it the 'still running as root' error. > >> Second, it is able to access the bayes_journal file (as long as > >> normal unix permissions are right, which I've figured out). So I > >> guess the problem is an SELinux issue which I can't solve. I'd attach > >> some avc error messages, but I can't seem to find any. I've looked in > >> maillog, secure, and messages, but nothing. > > Have you looked in the audit log, where all such messages are usually > > found ? > > /var/log/audit.log > > > Below is what showed up in audit/audit.log when I sent a message through > spamassassin. I'm _*really*_ rusty on SELinux...it's the one thing I > have to deal with quite often that I haven't been able to learn how to > use...it's so foreign to me. I've never looked in audit.log before: the > avc messages used to show up in messages, but now as far back as my logs > go, I don't have a single avc message. This all looks like jibberish to > me, so I need your guy's help. > > Thanks, > Justin > > type=AVC msg=audit(1138596151.681:104174): avc: denied { > name_connect } for pid=23796 comm="spamd" dest=389 > scontext=root:system_r:spamd_t > tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket > type=SYSCALL msg=audit(1138596151.681:104174): arch=40000003 > syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 > items=0 pid=23796 auid=600 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl" > type=SOCKADDR msg=audit(1138596151.681:104174): > saddr=02000185C0A801940000000000000000 > type=SOCKETCALL msg=audit(1138596151.681:104174): nargs=3 a0=7 > a1=9b1fe80 a2=10 > type=AVC msg=audit(1138596153.220:104175): avc: denied { > name_connect } for pid=23796 comm="spamd" dest=389 > scontext=root:system_r:spamd_t > tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket > type=SYSCALL msg=audit(1138596153.220:104175): arch=40000003 > syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 > items=0 pid=23796 auid=600 uid=0 gid=0 euid=99 suid=0 fsuid=99 > egid=99 sgid=0 fsgid=99 comm="spamd" exe="/usr/bin/perl" > type=SOCKADDR msg=audit(1138596153.220:104175): > saddr=02000185C0A801940000000000000000 > type=SOCKETCALL msg=audit(1138596153.220:104175): nargs=3 a0=7 > a1=9b6a6f0 a2=10 > type=AVC msg=audit(1138596160.388:104176): avc: denied { > name_connect } for pid=23797 comm="spamd" dest=389 > scontext=root:system_r:spamd_t > tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket > type=SYSCALL msg=audit(1138596160.388:104176): arch=40000003 > syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 > items=0 pid=23797 auid=600 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl" > type=SOCKADDR msg=audit(1138596160.388:104176): > saddr=02000185C0A801940000000000000000 > type=SOCKETCALL msg=audit(1138596160.388:104176): nargs=3 a0=7 > a1=9b20050 a2=10 > type=AVC msg=audit(1138596164.032:104177): avc: denied { > name_connect } for pid=23797 comm="spamd" dest=389 > scontext=root:system_r:spamd_t > tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket > type=SYSCALL msg=audit(1138596164.032:104177): arch=40000003 > syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 > items=0 pid=23797 auid=600 uid=0 gid=0 euid=99 suid=0 fsuid=99 > egid=99 sgid=0 fsgid=99 comm="spamd" exe="/usr/bin/perl" > type=SOCKADDR msg=audit(1138596164.032:104177): > saddr=02000185C0A801940000000000000000 > type=SOCKETCALL msg=audit(1138596164.032:104177): nargs=3 a0=7 > a1=9b84af0 a2=10 Are you using LDAP for authentication or to handle mail accounts? Paul. From maschino at jouy.inra.fr Mon Jan 30 09:20:18 2006 From: maschino at jouy.inra.fr (Emeric Maschino) Date: Mon, 30 Jan 2006 10:20:18 +0100 Subject: Denied { search } mingetty and can't log in In-Reply-To: <1138354247.5060.8.camel@localhost.localdomain> References: <1136886574.5079.29.camel@localhost.localdomain> <1137432900.29976.24.camel@localhost.localdomain> <1138354247.5060.8.camel@localhost.localdomain> Message-ID: <1138612818.29923.14.camel@localhost.localdomain> Hi, > Just to let you know that the above AVCs have been reported as bug > #178747, #178748, #178789, #178750 and #178753. It seems they're all due > to an ia64 specific issue (details in bug #178747). I don't know if my > original problem in enforcing mode with mingetty is also concerned by > this issue. Today kernel should provide a workaround for the AVCs in > permissive mode. I'll test it and let you know the result. With kernel 2.6.15-1.1878_FC5, execmod checks are disabled, so I'm no more getting the corresponding AVCs. Furthermore, I'm now able to start in enforcing mode (the problem with mingetty was also solved). However, from the audit.log file, I'm still getting denied read and search AVCs, mainly due to irqbalance and hald: type=AVC msg=audit(1138388575.636:9): avc: denied { read } for pid=1946 comm="irqbalance" name="mtab" dev=dm-0 ino=1899143 scontext=system_u:system_r:irqbalance_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file type=SYSCALL msg=audit(1138388575.636:9): arch=c0000032 syscall=1028 success=no exit=13 a0=20000008002ae8d0 a1=0 a2=1b6 a3=558281 items=1 pid=1946 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="irqbalance" exe="/usr/sbin/irqbalance" type=AVC msg=audit(1138388575.636:10): avc: denied { read } for pid=1946 comm="irqbalance" name="fstab" dev=dm-0 ino=1901326 scontext=system_u:system_r:irqbalance_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file type=SYSCALL msg=audit(1138388575.636:10): arch=c0000032 syscall=1028 success=no exit=13 a0=20000008002ae938 a1=0 a2=1b6 a3=558281 items=1 pid=1946 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="irqbalance" exe="/usr/sbin/irqbalance" type=AVC msg=audit(1138385008.409:11): avc: denied { search } for pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir type=AVC msg=audit(1138385008.477:12): avc: denied { search } for pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir type=AVC msg=audit(1138385008.593:13): avc: denied { search } for pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir type=AVC msg=audit(1138385008.677:14): avc: denied { search } for pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir type=AVC msg=audit(1138385008.733:15): avc: denied { search } for pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir type=AVC msg=audit(1138385012.697:17): avc: denied { search } for pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir Cheers, M From SeLinux at Compucenter.org Mon Jan 30 11:47:33 2006 From: SeLinux at Compucenter.org (G Jahchan) Date: Mon, 30 Jan 2006 13:47:33 +0200 Subject: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16 In-Reply-To: <1138390162.13075.373.camel@moss-spartans.epoch.ncsc.mil> Message-ID: I have not had time to do much testing, but first indications are that incorrect labeling was the culprit. I initiated a boot-time relabeling. When done, I restarted the system (in permissive mode), switched to enforcing mode (/usr/sbin/setenforce 1) and was able to log in normally from tty1, (while su'd as root in tty0) though there are plenty of 'avc: denied' messages in /var/log/messages and /var/log/audit/audit.log) that I need to look at. I still have the problem of reported Boolean errors that are scrolling too fast to read as selinux loads at boot time, and do not seem to be logged anywhere. Can you help with those? All I was able to make up from the fast-scrolling display is the word 'mozilla' repeated four or five times in an error message, followed by a Boolean error message. -----Original Message----- From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list-bounces at redhat.com]On Behalf Of Stephen Smalley Sent: Friday, January 27, 2006 21:29 To: Valdis.Kletnieks at vt.edu Cc: G Jahchan; Fedora SE Linux List Subject: Re: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16 On Fri, 2006-01-27 at 14:18 -0500, Valdis.Kletnieks at vt.edu wrote: > On Fri, 27 Jan 2006 11:44:07 EST, Stephen Smalley said: > > On Fri, 2006-01-27 at 17:49 +0200, G Jahchan wrote: > > > ls -Z /sbin/init > > > -rwxr-xr-x root root system_u:object_r:staff_home_t /sbin/init > > > > That's your problem - your filesystem is incorrectly labeled. Don't > > know how your /sbin/init program ended up with the type of a staff home > > directory; it should have init_exec_t. > > It's probably related to the strict policy whoopsage I reported - the system > would end up with only some 10% of the policy modules in place, and a restorecon > wouldn't include the *.fc rules for the missing modules - so some less-restrictive > rule would set the context (I ended up with almost everything as default_t, > but I could see how staff_home_t might happen too...) > > At one point, every single process on my laptop was running in kernel_t, because > the various init_t and similar types weren't defined, nor were the transitions for > them. Good thing I'm running in permissive. ;) Except that his message indicated that he is running FC4, not rawhide (look at his kernel and policy versions). -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list From sds at tycho.nsa.gov Mon Jan 30 14:37:28 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 30 Jan 2006 09:37:28 -0500 Subject: does selinux work with non-fedora package ? In-Reply-To: <5a3d805c0601291716y38c8613eo6dabe1967e8d1178@mail.gmail.com> References: <5a3d805c0601291716y38c8613eo6dabe1967e8d1178@mail.gmail.com> Message-ID: <1138631848.7076.39.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2006-01-30 at 08:16 +0700, ody quraviharto wrote: > hi all, > I am a Fedora newbie interesting in selinux. here are some questions > > 1. does selinux work well with reiserfs filesystem ? Not presently. Support for using reiserfs xattrs with SELinux went into Linux 2.6.12, but a change in Linux 2.6.14 to support atomic security labeling of new inodes broke it again. Getting it working again shouldn't be too difficult, but requires someone who cares to either make a patch and submit it to the reiserfs maintainers or to nag them until they do it themselves. > 2. does selinux work well with postgresql rpm packages I downloaded > from postgresql site ? It _should_, although there may be some variations in where the upstream packages put their files or their configuration that may require adjustment to the SELinux policy. -- Stephen Smalley National Security Agency From tiziano at conticars.be Mon Jan 30 14:35:57 2006 From: tiziano at conticars.be (Tiziano Demaria) Date: Mon, 30 Jan 2006 15:35:57 +0100 Subject: MySQL 5.0 and Fedora In-Reply-To: <1138631848.7076.39.camel@moss-spartans.epoch.ncsc.mil> References: <5a3d805c0601291716y38c8613eo6dabe1967e8d1178@mail.gmail.com> <1138631848.7076.39.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <43DE244D.9040407@conticars.be> Dear Friends i'm letterally on shit with FEDORA CORE 3and MySQL 5.0.xxxfrom MySQL official website. Practically MySQL works but doesn't work anymore with PHPADMIN...i've also updated php to the last version (from php.net)....but still problem... Do you have any solution please ? Thank you in advance, best regards Tiziano From sds at tycho.nsa.gov Mon Jan 30 15:28:03 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 30 Jan 2006 10:28:03 -0500 Subject: Nagios nrpe and sudo In-Reply-To: <1138486860.11412.21.camel@avenin.ebourne.me.uk> References: <1138486860.11412.21.camel@avenin.ebourne.me.uk> Message-ID: <1138634883.7076.48.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2006-01-28 at 22:21 +0000, Martin Ebourne wrote: > Hi, > > I'm getting AVC denied with a nagios nrpe script which needs to sudo. > The script works fine without selinux. I'm on FC4. > > nrpe is the remote execution feature in nagios. It runs under xinetd and > accepts incoming commands. It then runs scripts to fetch results. My > script to get harddisk smart attributes looks like so: > > ========== > #!/bin/sh > device="$1" > attribute="$2" > #id > sudo /usr/sbin/smartctl -A $device | perl -ne 'm{^\s*\Q'"$attribute"'\E > \s} && split && print "$_[9]"' > ========== > > During execution of the script id returns: > > uid=173(nagios) gid=173(nagios) context=system_u:system_r:inetd_t > > But I get this avc denial: > > type=AVC msg=audit(1138482709.249:31780): avc: denied { entrypoint } > for pid=11537 comm="sudo" name="sesh" dev=dm-0 ino=442643 > scontext=root:system_r:amanda_t tcontext=system_u:object_r:shell_exec_t > tclass=file amanda_t looks odd there. ls -Z /usr/sbin/smartctl sudo selinux patch has been reverted in rawhide, possibly should be done in FC4 as well. bug 178429 > Seems reasonable. There don't seem to be any booleans for nrpe but there > is inetd_child_disable_trans. With that set id gives: > > uid=173(nagios) gid=173(nagios) context=root:system_r:inetd_t > > But I get the same denial: > > type=AVC msg=audit(1138485617.391:32037): avc: denied { entrypoint } > for pid=14228 comm="sudo" name="sesh" dev=dm-0 ino=442643 > scontext=root:system_r:amanda_t tcontext=system_u:object_r:shell_exec_t > tclass=file > > I've no idea what amanda_t has got to do with any of this. Am I missing > something obvious? It seems to be running in the new context, but still > be protected. The inetd_child_disable_trans is described in > system-config-securitylevel as "Disable SELinux protection for inetd > child daemons", which is what I seem to need. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Jan 30 15:30:50 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 30 Jan 2006 10:30:50 -0500 Subject: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16 In-Reply-To: References: Message-ID: <1138635050.7076.52.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2006-01-30 at 13:47 +0200, G Jahchan wrote: > I have not had time to do much testing, but first indications are that > incorrect labeling was the culprit. > > I initiated a boot-time relabeling. When done, I restarted the system (in > permissive mode), switched to enforcing mode (/usr/sbin/setenforce 1) and was > able to log in normally from tty1, (while su'd as root in tty0) though there > are plenty of 'avc: denied' messages in /var/log/messages and > /var/log/audit/audit.log) that I need to look at. > > I still have the problem of reported Boolean errors that are scrolling too fast > to read as selinux loads at boot time, and do not seem to be logged anywhere. > Can you help with those? All I was able to make up from the fast-scrolling > display is the word 'mozilla' repeated four or five times in an error message, > followed by a Boolean error message. Likely just stale boolean settings in your booleans.local file, which are just skipped with a warning. To reproduce, run: /usr/sbin/load_policy -b /etc/selinux/targeted/policy/policy.19 If you have any "boolean ... no longer in policy" messages, just remove those lines from your /etc/selinux/targeted/booleans.local file. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Jan 30 15:35:44 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 30 Jan 2006 10:35:44 -0500 Subject: MySQL 5.0 and Fedora In-Reply-To: <43DE244D.9040407@conticars.be> References: <5a3d805c0601291716y38c8613eo6dabe1967e8d1178@mail.gmail.com> <1138631848.7076.39.camel@moss-spartans.epoch.ncsc.mil> <43DE244D.9040407@conticars.be> Message-ID: <1138635344.7076.58.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2006-01-30 at 15:35 +0100, Tiziano Demaria wrote: > Dear Friends > > i'm letterally on shit with FEDORA CORE 3and MySQL 5.0.xxxfrom MySQL > official website. > > Practically MySQL works but doesn't work anymore with PHPADMIN...i've > also updated php to the last version (from php.net)....but still problem... > Do you have any solution please ? > > Thank you in advance, best regards Make sure that your selinux-policy-targeted is up-to-date. On FC3, look in /var/log/messages for "avc: denied" messages. Those will show you SELinux permission denials. audit2allow can be used to turn those into allow rules to add to your policy, but be careful about doing so blindly. Certain booleans will let you customize behavior without adding new allow rules, settable via setsebool or system-config-securitylevel GUI. Since you mentioned php, read the contents of 'man httpd_selinux' and look at your httpd boolean settings (getsebool -a | grep httpd). -- Stephen Smalley National Security Agency From tiziano at conticars.be Mon Jan 30 15:30:15 2006 From: tiziano at conticars.be (Tiziano) Date: Mon, 30 Jan 2006 16:30:15 +0100 Subject: MySQL 5.0 and Fedora In-Reply-To: <1138635344.7076.58.camel@moss-spartans.epoch.ncsc.mil> References: <5a3d805c0601291716y38c8613eo6dabe1967e8d1178@mail.gmail.com> <1138631848.7076.39.camel@moss-spartans.epoch.ncsc.mil> <43DE244D.9040407@conticars.be> <1138635344.7076.58.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <43DE3107.8000606@conticars.be> I've deactivated SELinux since 7 months due too much problmes...so now it's under normal linux... Stephen Smalley wrote: >On Mon, 2006-01-30 at 15:35 +0100, Tiziano Demaria wrote: > > >>Dear Friends >> >>i'm letterally on shit with FEDORA CORE 3and MySQL 5.0.xxxfrom MySQL >>official website. >> >>Practically MySQL works but doesn't work anymore with PHPADMIN...i've >>also updated php to the last version (from php.net)....but still problem... >>Do you have any solution please ? >> >>Thank you in advance, best regards >> >> > >Make sure that your selinux-policy-targeted is up-to-date. > >On FC3, look in /var/log/messages for "avc: denied" messages. Those >will show you SELinux permission denials. audit2allow can be used to >turn those into allow rules to add to your policy, but be careful about >doing so blindly. > >Certain booleans will let you customize behavior without adding new >allow rules, settable via setsebool or system-config-securitylevel GUI. >Since you mentioned php, read the contents of 'man httpd_selinux' and >look at your httpd boolean settings (getsebool -a | grep httpd). > > > -- From tiziano at conticars.be Mon Jan 30 15:30:38 2006 From: tiziano at conticars.be (Tiziano) Date: Mon, 30 Jan 2006 16:30:38 +0100 Subject: MySQL 5.0 and Fedora In-Reply-To: <43DE2FF0.7010600@asric.com> References: <5a3d805c0601291716y38c8613eo6dabe1967e8d1178@mail.gmail.com> <1138631848.7076.39.camel@moss-spartans.epoch.ncsc.mil> <43DE244D.9040407@conticars.be> <43DE2FF0.7010600@asric.com> Message-ID: <43DE311E.1010802@conticars.be> I'm downloading it..and I'll try it... Steven Ringwald wrote: > Tiziano Demaria wrote: > >> Dear Friends >> >> i'm letterally on shit with FEDORA CORE 3and MySQL 5.0.xxxfrom MySQL >> official website. >> >> Practically MySQL works but doesn't work anymore with PHPADMIN...i've >> also updated php to the last version (from php.net)....but still >> problem... >> Do you have any solution please ? >> >> Thank you in advance, best regards > > > > I would highly recommend Xampp... I have found that it works really > well, and installs itself out-of-the-way, so it is easy to remove > should you have need to. > > http://www.apachefriends.org/en/xampp.html > > Steve > From dpaul at gmx.net Mon Jan 30 15:39:21 2006 From: dpaul at gmx.net (Daniel Paul) Date: Mon, 30 Jan 2006 16:39:21 +0100 Subject: Problem with interbase (firebird-1.5) on FC4 box, httpd-2.0.54, php-interbase-5.0.4-10.5 Message-ID: <200601301639.21188.dpaul@gmx.net> Hello there, because I need interbase (firebird) support in php, I recompiled the actual php-5.0.4-10.5 package with interbase support (--with-interbase=shared). When I start httpd there is the following message in error_log: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/interbase.so' - object requires: cannot enable executable stack as shared object requires: Permission denied in Unknown on line 0 phpinfo() shows that php has read the interbase.ini file which contains a reference to the interbase.so module, but interbase support is disabled (nothing shows up regarding interbase). With selinux set to permissive mode (instead of enforcing), there is no such message and phpinfo() shows me, that interbase support is enabled. audit.log shows the following: type=AVC msg=audit(1138630853.033:10): avc: denied { execstack } for pid=1886 comm="httpd" scontext=root:system_r:httpd_t tcontext=root:system_r:httpd_t tclass=process type=SYSCALL msg=audit(1138630853.033:10): arch=40000003 syscall=125 success=no exit=-13 a0=bf8a3000 a1=1000 a2=1000007 a3=d5a000 items=0 pid=1886 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd" exe="/usr/sbin/httpd" Any help would be truly appreciated. Thanks in advance, Daniel From sds at tycho.nsa.gov Mon Jan 30 15:55:24 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 30 Jan 2006 10:55:24 -0500 Subject: MySQL 5.0 and Fedora In-Reply-To: <43DE3107.8000606@conticars.be> References: <5a3d805c0601291716y38c8613eo6dabe1967e8d1178@mail.gmail.com> <1138631848.7076.39.camel@moss-spartans.epoch.ncsc.mil> <43DE244D.9040407@conticars.be> <1138635344.7076.58.camel@moss-spartans.epoch.ncsc.mil> <43DE3107.8000606@conticars.be> Message-ID: <1138636524.7076.76.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2006-01-30 at 16:30 +0100, Tiziano wrote: > I've deactivated SELinux since 7 months due too much problmes...so now > it's under normal linux... Then post to fedora-list rather than fedora-selinux-list. Much wider audience, more likely to get better help about general Fedora issues there. -- Stephen Smalley National Security Agency From dragoran at feuerpokemon.de Mon Jan 30 17:04:07 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 30 Jan 2006 18:04:07 +0100 Subject: extras package that require changes in selinux-policy (initng) Message-ID: <43DE4707.9010900@feuerpokemon.de> Hello. I am working on selinux support in initng, which is in review for extras now [1]. But it seems that initng requires a policy to work (just tested in targeted mode) Using the default context (sbin_t) lets all apps that are started from initng run as kernel_t. Relabling /sbin/initng to init_exec_t (same as init) fixes this and the processes run as init_t and udev_t for udev, but some issues still remain. hald,httpd, etc. also run as init_t which is *wrong* they have to get into their own domain. How is this handled in sysvinit? After reading the code I havn't found anything about it. The patch I wrote can be found here: http://bugzilla.initng.thinktux.net/show_bug.cgi?id=365 Did I do something wrong? Did I miss something? After fixing this we will run into an other problem. Every time the filesystem gots relabled initng will become sbin_t which will break it. To fix this we need to modify the selinux-policy. What should be done if a package in extras requires to change a core package? Should I just fill a bug against it and hope that it will be released as an update for FC4, and gets into rawhide too? Was unable to find anything about it in the wiki. 1: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 From dragoran at feuerpokemon.de Mon Jan 30 18:31:02 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 30 Jan 2006 19:31:02 +0100 Subject: mono (beagle) + execmem Message-ID: <43DE5B66.8030902@feuerpokemon.de> it seems that beagle/mono requires execmem but this is disabled in the policy for them? is this a known bug or should I fill it? From dwalsh at redhat.com Mon Jan 30 19:25:55 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 30 Jan 2006 14:25:55 -0500 Subject: macros in old policy In-Reply-To: <1138381614.29650.23.camel@faith.austin.ibm.com> References: <1138381614.29650.23.camel@faith.austin.ibm.com> Message-ID: <43DE6843.6080208@redhat.com> Joy Latten wrote: > I am converting the selinux testsuite policy to reference policy. > The old test policy used the macros, can_setcon, can_setexec, > can_setfscreate. These macros are not existent in the source for > current refpolicy. Will these macros be included in refpolicy or > obsolete, or do I write them myself in the test module, or do they map > to something else now? Just wondering what is the correct thing to do? > > Regards, > Joy Latten > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Looks like you need to create these yourself. From dwalsh at redhat.com Mon Jan 30 19:33:29 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 30 Jan 2006 14:33:29 -0500 Subject: extras package that require changes in selinux-policy (initng) In-Reply-To: <43DE4707.9010900@feuerpokemon.de> References: <43DE4707.9010900@feuerpokemon.de> Message-ID: <43DE6A09.2040602@redhat.com> dragoran wrote: > Hello. > I am working on selinux support in initng, which is in review for > extras now [1]. > But it seems that initng requires a policy to work (just tested in > targeted mode) > Using the default context (sbin_t) lets all apps that are started from > initng run as kernel_t. What is the path? We can set it up in policy. > Relabling /sbin/initng to init_exec_t (same as init) fixes this and > the processes run as init_t and udev_t for udev, but some issues still > remain. I will add to policy. > hald,httpd, etc. also run as init_t which is *wrong* they have to get > into their own domain. How is this handled in sysvinit? > After reading the code I havn't found anything about it. Are the startup scripts marked initrc_exec_t? > The patch I wrote can be found here: > http://bugzilla.initng.thinktux.net/show_bug.cgi?id=365 > Did I do something wrong? Did I miss something? > After fixing this we will run into an other problem. Every time the > filesystem gots relabled initng will become sbin_t which will break it. > To fix this we need to modify the selinux-policy. What should be done > if a package in extras requires to change a core package? > Should I just fill a bug against it and hope that it will be released > as an update for FC4, and gets into rawhide too? > Was unable to find anything about it in the wiki. > 1: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Mon Jan 30 19:34:17 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 30 Jan 2006 14:34:17 -0500 Subject: mono (beagle) + execmem In-Reply-To: <43DE5B66.8030902@feuerpokemon.de> References: <43DE5B66.8030902@feuerpokemon.de> Message-ID: <43DE6A39.1070301@redhat.com> dragoran wrote: > it seems that beagle/mono requires execmem but this is disabled in the > policy for them? > is this a known bug or should I fill it? > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Mono is supposed to be allowed execmem? Check the labeleing on the executable. Should be mono_exec_t. From dwalsh at redhat.com Mon Jan 30 19:35:00 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 30 Jan 2006 14:35:00 -0500 Subject: su, context(selinux?) 2nd prompt In-Reply-To: <1138398133.10271.12.camel@krs> References: <43D4FAAF.6020108@redhat.com> <43D7B02E.7070004@redhat.com> <1138398133.10271.12.camel@krs> Message-ID: <43DE6A64.8030206@redhat.com> Kanwar Ranbir Sandhu wrote: > On Wed, 2006-25-01 at 12:06 -0500, Daniel J Walsh wrote: > >>>> Remove multiple from the pam file. >>>> >>>> >>> editing /etc/pam.d/su, changing >>> session required /lib/security/$ISA/pam_selinux.so open multiple >>> to >>> session required /lib/security/$ISA/pam_selinux.so open >>> >>> Did the trick, thanks Dan! >>> >>> # rpm -q -f /etc/pam.d/su >>> coreutils-5.2.1-31.2 >>> >>> >>> >> You can actually remove the pam_selinux.so lines from the su file >> altogether. We have done this for FC5 and it works >> fine. In strict or MLS Policy you will be required to run newrole but >> in targeted everything should just work. >> > > I'm seeing the same behaviour with telnetd. I had to install it for a > client that runs a text based app which Windows users telnet into (it's > only open to the local network, and the app loads immediately after > login). > > When a user logs in via telnet, the same question appears. I told my > client to just accept the default answer, which is "no". Ideally, I'd > like to remove the option all together. > > I assume it's possible to turn it off like it was for "su", but I'm not > sure which file to edit. /etc/pam.d/login looks like the closest one, > specifically this line: > > # pam_selinux.so open should be the last session rule > session required pam_selinux.so multiple open > > I'm not sure though. Any tips? > > Regards, > > Ranbir > > Remove multiple for the pam_selinux line. From lists at ebourne.me.uk Mon Jan 30 22:11:22 2006 From: lists at ebourne.me.uk (Martin Ebourne) Date: Mon, 30 Jan 2006 22:11:22 +0000 Subject: Nagios nrpe and sudo In-Reply-To: <1138634883.7076.48.camel@moss-spartans.epoch.ncsc.mil> References: <1138486860.11412.21.camel@avenin.ebourne.me.uk> <1138634883.7076.48.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1138659082.6632.3.camel@avenin.ebourne.me.uk> On Mon, 2006-01-30 at 10:28 -0500, Stephen Smalley wrote: > amanda_t looks odd there. > ls -Z /usr/sbin/smartctl # ls -Z /usr/sbin/smartctl -rwxr-xr-x root root system_u:object_r:fsadm_exec_t /usr/sbin/smartctl > sudo selinux patch has been reverted in rawhide, possibly should be done > in FC4 as well. bug 178429 Rebuilt FC4 sudo-1.6.8p8-2.4 without the two selinux patches: that's fixed it thanks! I'm not using NOEXEC though. Cheers, Martin. From lists at ebourne.me.uk Mon Jan 30 22:19:30 2006 From: lists at ebourne.me.uk (Martin Ebourne) Date: Mon, 30 Jan 2006 22:19:30 +0000 Subject: Nagios nrpe and sudo In-Reply-To: <1138659082.6632.3.camel@avenin.ebourne.me.uk> References: <1138486860.11412.21.camel@avenin.ebourne.me.uk> <1138634883.7076.48.camel@moss-spartans.epoch.ncsc.mil> <1138659082.6632.3.camel@avenin.ebourne.me.uk> Message-ID: <1138659571.6632.5.camel@avenin.ebourne.me.uk> On Mon, 2006-01-30 at 22:11 +0000, Martin Ebourne wrote: > On Mon, 2006-01-30 at 10:28 -0500, Stephen Smalley wrote: > > amanda_t looks odd there. > > ls -Z /usr/sbin/smartctl > > # ls -Z /usr/sbin/smartctl > -rwxr-xr-x root root system_u:object_r:fsadm_exec_t /usr/sbin/smartctl > > > sudo selinux patch has been reverted in rawhide, possibly should be done > > in FC4 as well. bug 178429 > > Rebuilt FC4 sudo-1.6.8p8-2.4 without the two selinux patches: that's > fixed it thanks! I'm not using NOEXEC though. Further to this, I note that I don't even need the inetd_child_disable_trans boolean set now. By default nrpe running under xinetd is allowed to sudo. Should this not be controlled? What protection does running xinetd under selinux give? Cheers, Martin. From justin at jdjlab.com Mon Jan 30 22:39:55 2006 From: justin at jdjlab.com (Justin Willmert) Date: Mon, 30 Jan 2006 16:39:55 -0600 Subject: Spamassassin emails have wrong perms -- CC'ed to selinux list In-Reply-To: <1138607599.29207.35.camel@laurel.intra.city-fan.org> References: <43DD5D06.5020004@jdjlab.com> <43DD89FE.8000003@jdjlab.com> <43DD982C.3010702@cornell.edu> <43DD9B86.9000406@jdjlab.com> <1138607599.29207.35.camel@laurel.intra.city-fan.org> Message-ID: <43DE95BB.6000208@jdjlab.com> Paul Howarth wrote: > On Sun, 2006-01-29 at 22:52 -0600, Justin Willmert wrote: >> Ivan Gyurdiev wrote: >>>> I'm cc-ing this to the fedora-selinux-list. I think some of the >>>> problems may be applicable there. >>>> >>>> OK, after some more testing, when I disable SELinux, many of the >>>> errors go away. First of all, I get rid of the error message saying >>>> user can not be found and with it the 'still running as root' error. >>>> Second, it is able to access the bayes_journal file (as long as >>>> normal unix permissions are right, which I've figured out). So I >>>> guess the problem is an SELinux issue which I can't solve. I'd attach >>>> some avc error messages, but I can't seem to find any. I've looked in >>>> maillog, secure, and messages, but nothing. >>> Have you looked in the audit log, where all such messages are usually >>> found ? >>> /var/log/audit.log >>> >> Below is what showed up in audit/audit.log when I sent a message through >> spamassassin. I'm _*really*_ rusty on SELinux...it's the one thing I >> have to deal with quite often that I haven't been able to learn how to >> use...it's so foreign to me. I've never looked in audit.log before: the >> avc messages used to show up in messages, but now as far back as my logs >> go, I don't have a single avc message. This all looks like jibberish to >> me, so I need your guy's help. >> >> Thanks, >> Justin >> >> type=AVC msg=audit(1138596151.681:104174): avc: denied { >> name_connect } for pid=23796 comm="spamd" dest=389 >> scontext=root:system_r:spamd_t >> tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket >> type=SYSCALL msg=audit(1138596151.681:104174): arch=40000003 >> syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 >> items=0 pid=23796 auid=600 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 >> sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl" >> type=SOCKADDR msg=audit(1138596151.681:104174): >> saddr=02000185C0A801940000000000000000 >> type=SOCKETCALL msg=audit(1138596151.681:104174): nargs=3 a0=7 >> a1=9b1fe80 a2=10 >> type=AVC msg=audit(1138596153.220:104175): avc: denied { >> name_connect } for pid=23796 comm="spamd" dest=389 >> scontext=root:system_r:spamd_t >> tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket >> type=SYSCALL msg=audit(1138596153.220:104175): arch=40000003 >> syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 >> items=0 pid=23796 auid=600 uid=0 gid=0 euid=99 suid=0 fsuid=99 >> egid=99 sgid=0 fsgid=99 comm="spamd" exe="/usr/bin/perl" >> type=SOCKADDR msg=audit(1138596153.220:104175): >> saddr=02000185C0A801940000000000000000 >> type=SOCKETCALL msg=audit(1138596153.220:104175): nargs=3 a0=7 >> a1=9b6a6f0 a2=10 >> type=AVC msg=audit(1138596160.388:104176): avc: denied { >> name_connect } for pid=23797 comm="spamd" dest=389 >> scontext=root:system_r:spamd_t >> tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket >> type=SYSCALL msg=audit(1138596160.388:104176): arch=40000003 >> syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 >> items=0 pid=23797 auid=600 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 >> sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl" >> type=SOCKADDR msg=audit(1138596160.388:104176): >> saddr=02000185C0A801940000000000000000 >> type=SOCKETCALL msg=audit(1138596160.388:104176): nargs=3 a0=7 >> a1=9b20050 a2=10 >> type=AVC msg=audit(1138596164.032:104177): avc: denied { >> name_connect } for pid=23797 comm="spamd" dest=389 >> scontext=root:system_r:spamd_t >> tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket >> type=SYSCALL msg=audit(1138596164.032:104177): arch=40000003 >> syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 >> items=0 pid=23797 auid=600 uid=0 gid=0 euid=99 suid=0 fsuid=99 >> egid=99 sgid=0 fsgid=99 comm="spamd" exe="/usr/bin/perl" >> type=SOCKADDR msg=audit(1138596164.032:104177): >> saddr=02000185C0A801940000000000000000 >> type=SOCKETCALL msg=audit(1138596164.032:104177): nargs=3 a0=7 >> a1=9b84af0 a2=10 > > Are you using LDAP for authentication or to handle mail accounts? > > Paul. No, I am not using LDAP in spamassassin itself (there are ldap arguments to spamd and I'm not using those), but my system uses LDAP authentication through nsswitch/pam (whatever the distinction is). Does spamd need to know my ldap server's information? I believe I found a temporary work around for the bayes files: I put them in a non-standard location (/etc/mail/bayes/) because I wanted a system-wide database (some users don't get enough spam to warrant their own database). I found if I set /etc/mail/bayes/ to user_home_dir_t and /etc/mail/bayes/* to user_home_t that the denied messages for files are gone (if I'm reading the logs right). I don't see the file denial messages in the log output I put above, but they are in audit.log and in the latest test, they aren't there so I'm hoping I'm looking into all of this right. If you want me to confirm all of this, I can reset the directory context and do some tests, then set up the directory context again and compare that result, somebody just has to ask. Now I've just got to solve the LDAP messages. I'll try to look into this a bit, but I'm probably going to need the help, so thanks to all those who take time to reply. Justin From sds at tycho.nsa.gov Tue Jan 31 12:12:07 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 31 Jan 2006 07:12:07 -0500 Subject: Nagios nrpe and sudo In-Reply-To: <1138659571.6632.5.camel@avenin.ebourne.me.uk> References: <1138486860.11412.21.camel@avenin.ebourne.me.uk> <1138634883.7076.48.camel@moss-spartans.epoch.ncsc.mil> <1138659082.6632.3.camel@avenin.ebourne.me.uk> <1138659571.6632.5.camel@avenin.ebourne.me.uk> Message-ID: <1138709527.7076.226.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2006-01-30 at 22:19 +0000, Martin Ebourne wrote: > Further to this, I note that I don't even need the > inetd_child_disable_trans boolean set now. By default nrpe running under > xinetd is allowed to sudo. Should this not be controlled? > > What protection does running xinetd under selinux give? IIRC, the default targeted policy in Fedora leaves inetd children who do not have a specific domain defined for them unconfined, as otherwise all external (outside of Fedora) inetd-based services that lack policy would immediately break. The strict policy takes the more conservative approach for security, at the risk of greater application breakage. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Jan 31 12:30:43 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 31 Jan 2006 07:30:43 -0500 Subject: Nagios nrpe and sudo In-Reply-To: <1138709527.7076.226.camel@moss-spartans.epoch.ncsc.mil> References: <1138486860.11412.21.camel@avenin.ebourne.me.uk> <1138634883.7076.48.camel@moss-spartans.epoch.ncsc.mil> <1138659082.6632.3.camel@avenin.ebourne.me.uk> <1138659571.6632.5.camel@avenin.ebourne.me.uk> <1138709527.7076.226.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1138710643.7076.240.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-01-31 at 07:12 -0500, Stephen Smalley wrote: > On Mon, 2006-01-30 at 22:19 +0000, Martin Ebourne wrote: > > Further to this, I note that I don't even need the > > inetd_child_disable_trans boolean set now. By default nrpe running under > > xinetd is allowed to sudo. Should this not be controlled? > > > > What protection does running xinetd under selinux give? > > IIRC, the default targeted policy in Fedora leaves inetd children who do > not have a specific domain defined for them unconfined, as otherwise all > external (outside of Fedora) inetd-based services that lack policy would > immediately break. The strict policy takes the more conservative > approach for security, at the risk of greater application breakage. Ah, sorry, but your point was that nrpe should be confined since it has policy. However, it appears that the nagios and nrpe policies aren't being built as part of the Fedora policy at present. -- Stephen Smalley National Security Agency From selinux at gmail.com Tue Jan 31 15:28:06 2006 From: selinux at gmail.com (Tom London) Date: Tue, 31 Jan 2006 07:28:06 -0800 Subject: More changes to NetworkManager for WPA... (yea!) Message-ID: <4c4ba1530601310728q4a8b96c4ma55616264a6f2a91@mail.gmail.com> Running today's rawhide, targeted/enforcing. The new kernel and NM supports WPA. Works in permissive mode. Seems to want: allow NetworkManager_t self:unix_dgram_socket sendto; allow NetworkManager_t tmp_t:dir remove_name; allow NetworkManager_t tmp_t:sock_file unlink; allow NetworkManager_t var_run_t:dir create; allow NetworkManager_t var_run_t:sock_file setattr; ---- type=PATH msg=audit(01/31/2006 07:17:14.277:45) : item=0 flags=parent inode=2777160 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 type=SOCKETCALL msg=audit(01/31/2006 07:17:14.277:45) : nargs=3 a0=3 a1=bfd8f0fe a2=6e type=SOCKADDR msg=audit(01/31/2006 07:17:14.277:45) : saddr=local /var/run/wpa_supplicant-global type=SYSCALL msg=audit(01/31/2006 07:17:14.277:45) : arch=i386 syscall=socketcall(bind) success=yes exit=0 a0=2 a1=bfd8f0e0 a2=3 a3=8af7020 items=1 pid=3138 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=wpa_supplicant exe=/usr/sbin/wpa_supplicant type=AVC msg=audit(01/31/2006 07:17:14.277:45) : avc: denied { create } for pid=3138 comm=wpa_supplicant name=wpa_supplicant-global scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file ---- type=PATH msg=audit(01/31/2006 07:17:15.281:46) : item=0 flags=parent inode=980161 dev=fd:00 mode=dir,sticky,777 ouid=root ogid=root rdev=00:00 type=SOCKETCALL msg=audit(01/31/2006 07:17:15.281:46) : nargs=3 a0=12 a1=810f9ac a2=6e type=SOCKADDR msg=audit(01/31/2006 07:17:15.281:46) : saddr=local /tmp/wpa_ctrl_2606-1 type=SYSCALL msg=audit(01/31/2006 07:17:15.281:46) : arch=i386 syscall=socketcall(bind) success=yes exit=0 a0=2 a1=b7579240 a2=1 a3=810f9a8 items=1 pid=2615 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=NetworkManager exe=/usr/sbin/NetworkManager type=AVC msg=audit(01/31/2006 07:17:15.281:46) : avc: denied { create } for pid=2615 comm=NetworkManager name=wpa_ctrl_2606-1 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file type=AVC msg=audit(01/31/2006 07:17:15.281:46) : avc: denied { add_name } for pid=2615 comm=NetworkManager name=wpa_ctrl_2606-1 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(01/31/2006 07:17:15.281:46) : avc: denied { write } for pid=2615 comm=NetworkManager name=tmp dev=dm-0 ino=980161 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(01/31/2006 07:17:15.281:46) : avc: denied { search } for pid=2615 comm=NetworkManager name=tmp dev=dm-0 ino=980161 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir ---- type=PATH msg=audit(01/31/2006 07:17:15.281:47) : item=0 flags=follow inode=2778180 dev=fd:00 mode=socket,755 ouid=root ogid=root rdev=00:00 type=SOCKETCALL msg=audit(01/31/2006 07:17:15.281:47) : nargs=3 a0=12 a1=810fa1a a2=6e type=SOCKADDR msg=audit(01/31/2006 07:17:15.281:47) : saddr=local /var/run/wpa_supplicant-global type=AVC_PATH msg=audit(01/31/2006 07:17:15.281:47) : path=/var/run/wpa_supplicant-global type=SYSCALL msg=audit(01/31/2006 07:17:15.281:47) : arch=i386 syscall=socketcall(connect) success=yes exit=0 a0=3 a1=b7579240 a2=1 a3=0 items=1 pid=2615 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=NetworkManager exe=/usr/sbin/NetworkManager type=AVC msg=audit(01/31/2006 07:17:15.281:47) : avc: denied { sendto } for pid=2615 comm=NetworkManager name=wpa_supplicant-global scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:NetworkManager_t:s0 tclass=unix_dgram_socket type=AVC msg=audit(01/31/2006 07:17:15.281:47) : avc: denied { write } for pid=2615 comm=NetworkManager name=wpa_supplicant-global dev=dm-0 ino=2778180 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file ---- type=PATH msg=audit(01/31/2006 07:17:15.309:48) : item=0 name=/var/run/wpa_supplicant flags=parent inode=2777160 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/31/2006 07:17:15.309:48) : cwd=/ type=SYSCALL msg=audit(01/31/2006 07:17:15.309:48) : arch=i386 syscall=mkdir success=yes exit=0 a0=8af7aa8 a1=1f8 a2=8af7958 a3=8af7958 items=1 pid=3138 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=wpa_supplicant exe=/usr/sbin/wpa_supplicant type=AVC msg=audit(01/31/2006 07:17:15.309:48) : avc: denied { create } for pid=3138 comm=wpa_supplicant name=wpa_supplicant scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=dir ---- type=PATH msg=audit(01/31/2006 07:17:15.465:49) : item=0 name=/var/run/wpa_supplicant/eth1 flags=follow inode=3628151 dev=fd:00 mode=socket,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/31/2006 07:17:15.465:49) : cwd=/ type=SYSCALL msg=audit(01/31/2006 07:17:15.465:49) : arch=i386 syscall=chmod success=yes exit=0 a0=8b00e68 a1=1f8 a2=8b00e68 a3=8af7958 items=1 pid=3138 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=wpa_supplicant exe=/usr/sbin/wpa_supplicant type=AVC msg=audit(01/31/2006 07:17:15.465:49) : avc: denied { setattr } for pid=3138 comm=wpa_supplicant name=eth1 dev=dm-0 ino=3628151 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file ---- type=AVC msg=audit(01/31/2006 07:17:15.465:50) : avc: denied { write } for pid=3138 comm=wpa_supplicant name=wpa_ctrl_2606-1 dev=dm-0 ino=980237 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file ---- type=PATH msg=audit(01/31/2006 07:17:15.465:51) : item=0 name=/tmp/wpa_ctrl_2606-1 flags=parent inode=980161 dev=fd:00 mode=dir,sticky,777 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(01/31/2006 07:17:15.465:51) : cwd=/ type=SYSCALL msg=audit(01/31/2006 07:17:15.465:51) : arch=i386 syscall=unlink success=yes exit=0 a0=810f9ae a1=1 a2=810f9a8 a3=81084b0 items=1 pid=2615 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=NetworkManager exe=/usr/sbin/NetworkManager type=AVC msg=audit(01/31/2006 07:17:15.465:51) : avc: denied { unlink } for pid=2615 comm=NetworkManager name=wpa_ctrl_2606-1 dev=dm-0 ino=980237 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file type=AVC msg=audit(01/31/2006 07:17:15.465:51) : avc: denied { remove_name } for pid=2615 comm=NetworkManager name=wpa_ctrl_2606-1 dev=dm-0 ino=980237 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir ---- type=PATH msg=audit(01/31/2006 07:17:15.465:50) : item=0 flags=follow inode=980237 dev=fd:00 mode=socket,755 ouid=root ogid=root rdev=00:00 type=SOCKETCALL msg=audit(01/31/2006 07:17:15.465:50) : nargs=6 a0=3 a1=8af7150 a2=3 a3=0 a4=bfd8f0b6 a5=17 type=SOCKADDR msg=audit(01/31/2006 07:17:15.465:50) : saddr=local /tmp/wpa_ctrl_2606-1 type=SYSCALL msg=audit(01/31/2006 07:17:15.465:50) : arch=i386 syscall=socketcall(sendto) success=yes exit=3 a0=b a1=bfd8ef80 a2=bfd8efc4 a3=0 items=1 pid=3138 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=wpa_supplicant exe=/usr/sbin/wpa_supplicant -- Tom London From dwalsh at redhat.com Tue Jan 31 15:43:31 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 31 Jan 2006 10:43:31 -0500 Subject: More changes to NetworkManager for WPA... (yea!) In-Reply-To: <4c4ba1530601310728q4a8b96c4ma55616264a6f2a91@mail.gmail.com> References: <4c4ba1530601310728q4a8b96c4ma55616264a6f2a91@mail.gmail.com> Message-ID: <43DF85A3.9030607@redhat.com> Tom London wrote: > Running today's rawhide, targeted/enforcing. > > The new kernel and NM supports WPA. Works in permissive mode. > > Seems to want: > allow NetworkManager_t self:unix_dgram_socket sendto; > allow NetworkManager_t tmp_t:dir remove_name; > allow NetworkManager_t tmp_t:sock_file unlink; > allow NetworkManager_t var_run_t:dir create; > allow NetworkManager_t var_run_t:sock_file setattr; > > Yes I am working with the NetworkManager maintainer to fix some problems in the design of NetworkManager/wpa So hopefully we can get this fixed by tomorrow. Dan > ---- > type=PATH msg=audit(01/31/2006 07:17:14.277:45) : item=0 flags=parent > inode=2777160 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 > type=SOCKETCALL msg=audit(01/31/2006 07:17:14.277:45) : nargs=3 a0=3 > a1=bfd8f0fe a2=6e > type=SOCKADDR msg=audit(01/31/2006 07:17:14.277:45) : saddr=local > /var/run/wpa_supplicant-global > type=SYSCALL msg=audit(01/31/2006 07:17:14.277:45) : arch=i386 > syscall=socketcall(bind) success=yes exit=0 a0=2 a1=bfd8f0e0 a2=3 > a3=8af7020 items=1 pid=3138 auid=unknown(4294967295) uid=root gid=root > euid=root suid=root fsuid=root egid=root sgid=root fsgid=root > comm=wpa_supplicant exe=/usr/sbin/wpa_supplicant > type=AVC msg=audit(01/31/2006 07:17:14.277:45) : avc: denied { > create } for pid=3138 comm=wpa_supplicant name=wpa_supplicant-global > scontext=system_u:system_r:NetworkManager_t:s0 > tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file > ---- > type=PATH msg=audit(01/31/2006 07:17:15.281:46) : item=0 flags=parent > inode=980161 dev=fd:00 mode=dir,sticky,777 ouid=root ogid=root > rdev=00:00 > type=SOCKETCALL msg=audit(01/31/2006 07:17:15.281:46) : nargs=3 a0=12 > a1=810f9ac a2=6e > type=SOCKADDR msg=audit(01/31/2006 07:17:15.281:46) : saddr=local > /tmp/wpa_ctrl_2606-1 > type=SYSCALL msg=audit(01/31/2006 07:17:15.281:46) : arch=i386 > syscall=socketcall(bind) success=yes exit=0 a0=2 a1=b7579240 a2=1 > a3=810f9a8 items=1 pid=2615 auid=unknown(4294967295) uid=root gid=root > euid=root suid=root fsuid=root egid=root sgid=root fsgid=root > comm=NetworkManager exe=/usr/sbin/NetworkManager > type=AVC msg=audit(01/31/2006 07:17:15.281:46) : avc: denied { > create } for pid=2615 comm=NetworkManager name=wpa_ctrl_2606-1 > scontext=system_u:system_r:NetworkManager_t:s0 > tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file > type=AVC msg=audit(01/31/2006 07:17:15.281:46) : avc: denied { > add_name } for pid=2615 comm=NetworkManager name=wpa_ctrl_2606-1 > scontext=system_u:system_r:NetworkManager_t:s0 > tcontext=system_u:object_r:tmp_t:s0 tclass=dir > type=AVC msg=audit(01/31/2006 07:17:15.281:46) : avc: denied { write > } for pid=2615 comm=NetworkManager name=tmp dev=dm-0 ino=980161 > scontext=system_u:system_r:NetworkManager_t:s0 > tcontext=system_u:object_r:tmp_t:s0 tclass=dir > type=AVC msg=audit(01/31/2006 07:17:15.281:46) : avc: denied { > search } for pid=2615 comm=NetworkManager name=tmp dev=dm-0 > ino=980161 scontext=system_u:system_r:NetworkManager_t:s0 > tcontext=system_u:object_r:tmp_t:s0 tclass=dir > ---- > type=PATH msg=audit(01/31/2006 07:17:15.281:47) : item=0 flags=follow > inode=2778180 dev=fd:00 mode=socket,755 ouid=root ogid=root rdev=00:00 > type=SOCKETCALL msg=audit(01/31/2006 07:17:15.281:47) : nargs=3 a0=12 > a1=810fa1a a2=6e > type=SOCKADDR msg=audit(01/31/2006 07:17:15.281:47) : saddr=local > /var/run/wpa_supplicant-global > type=AVC_PATH msg=audit(01/31/2006 07:17:15.281:47) : > path=/var/run/wpa_supplicant-global > type=SYSCALL msg=audit(01/31/2006 07:17:15.281:47) : arch=i386 > syscall=socketcall(connect) success=yes exit=0 a0=3 a1=b7579240 a2=1 > a3=0 items=1 pid=2615 auid=unknown(4294967295) uid=root gid=root > euid=root suid=root fsuid=root egid=root sgid=root fsgid=root > comm=NetworkManager exe=/usr/sbin/NetworkManager > type=AVC msg=audit(01/31/2006 07:17:15.281:47) : avc: denied { > sendto } for pid=2615 comm=NetworkManager name=wpa_supplicant-global > scontext=system_u:system_r:NetworkManager_t:s0 > tcontext=system_u:system_r:NetworkManager_t:s0 > tclass=unix_dgram_socket > type=AVC msg=audit(01/31/2006 07:17:15.281:47) : avc: denied { write > } for pid=2615 comm=NetworkManager name=wpa_supplicant-global > dev=dm-0 ino=2778180 scontext=system_u:system_r:NetworkManager_t:s0 > tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file > ---- > type=PATH msg=audit(01/31/2006 07:17:15.309:48) : item=0 > name=/var/run/wpa_supplicant flags=parent inode=2777160 dev=fd:00 > mode=dir,755 ouid=root ogid=root rdev=00:00 > type=CWD msg=audit(01/31/2006 07:17:15.309:48) : cwd=/ > type=SYSCALL msg=audit(01/31/2006 07:17:15.309:48) : arch=i386 > syscall=mkdir success=yes exit=0 a0=8af7aa8 a1=1f8 a2=8af7958 > a3=8af7958 items=1 pid=3138 auid=unknown(4294967295) uid=root gid=root > euid=root suid=root fsuid=root egid=root sgid=root fsgid=root > comm=wpa_supplicant exe=/usr/sbin/wpa_supplicant > type=AVC msg=audit(01/31/2006 07:17:15.309:48) : avc: denied { > create } for pid=3138 comm=wpa_supplicant name=wpa_supplicant > scontext=system_u:system_r:NetworkManager_t:s0 > tcontext=system_u:object_r:var_run_t:s0 tclass=dir > ---- > type=PATH msg=audit(01/31/2006 07:17:15.465:49) : item=0 > name=/var/run/wpa_supplicant/eth1 flags=follow inode=3628151 dev=fd:00 > mode=socket,755 ouid=root ogid=root rdev=00:00 > type=CWD msg=audit(01/31/2006 07:17:15.465:49) : cwd=/ > type=SYSCALL msg=audit(01/31/2006 07:17:15.465:49) : arch=i386 > syscall=chmod success=yes exit=0 a0=8b00e68 a1=1f8 a2=8b00e68 > a3=8af7958 items=1 pid=3138 auid=unknown(4294967295) uid=root gid=root > euid=root suid=root fsuid=root egid=root sgid=root fsgid=root > comm=wpa_supplicant exe=/usr/sbin/wpa_supplicant > type=AVC msg=audit(01/31/2006 07:17:15.465:49) : avc: denied { > setattr } for pid=3138 comm=wpa_supplicant name=eth1 dev=dm-0 > ino=3628151 scontext=system_u:system_r:NetworkManager_t:s0 > tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file > ---- > type=AVC msg=audit(01/31/2006 07:17:15.465:50) : avc: denied { write > } for pid=3138 comm=wpa_supplicant name=wpa_ctrl_2606-1 dev=dm-0 > ino=980237 scontext=system_u:system_r:NetworkManager_t:s0 > tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file > ---- > type=PATH msg=audit(01/31/2006 07:17:15.465:51) : item=0 > name=/tmp/wpa_ctrl_2606-1 flags=parent inode=980161 dev=fd:00 > mode=dir,sticky,777 ouid=root ogid=root rdev=00:00 > type=CWD msg=audit(01/31/2006 07:17:15.465:51) : cwd=/ > type=SYSCALL msg=audit(01/31/2006 07:17:15.465:51) : arch=i386 > syscall=unlink success=yes exit=0 a0=810f9ae a1=1 a2=810f9a8 > a3=81084b0 items=1 pid=2615 auid=unknown(4294967295) uid=root gid=root > euid=root suid=root fsuid=root egid=root sgid=root fsgid=root > comm=NetworkManager exe=/usr/sbin/NetworkManager > type=AVC msg=audit(01/31/2006 07:17:15.465:51) : avc: denied { > unlink } for pid=2615 comm=NetworkManager name=wpa_ctrl_2606-1 > dev=dm-0 ino=980237 scontext=system_u:system_r:NetworkManager_t:s0 > tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file > type=AVC msg=audit(01/31/2006 07:17:15.465:51) : avc: denied { > remove_name } for pid=2615 comm=NetworkManager name=wpa_ctrl_2606-1 > dev=dm-0 ino=980237 scontext=system_u:system_r:NetworkManager_t:s0 > tcontext=system_u:object_r:tmp_t:s0 tclass=dir > ---- > type=PATH msg=audit(01/31/2006 07:17:15.465:50) : item=0 flags=follow > inode=980237 dev=fd:00 mode=socket,755 ouid=root ogid=root rdev=00:00 > type=SOCKETCALL msg=audit(01/31/2006 07:17:15.465:50) : nargs=6 a0=3 > a1=8af7150 a2=3 a3=0 a4=bfd8f0b6 a5=17 > type=SOCKADDR msg=audit(01/31/2006 07:17:15.465:50) : saddr=local > /tmp/wpa_ctrl_2606-1 > type=SYSCALL msg=audit(01/31/2006 07:17:15.465:50) : arch=i386 > syscall=socketcall(sendto) success=yes exit=3 a0=b a1=bfd8ef80 > a2=bfd8efc4 a3=0 items=1 pid=3138 auid=unknown(4294967295) uid=root > gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root > comm=wpa_supplicant exe=/usr/sbin/wpa_supplicant > > > -- > Tom London > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From dragoran at feuerpokemon.de Tue Jan 31 15:47:40 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 31 Jan 2006 16:47:40 +0100 Subject: extras package that require changes in selinux-policy (initng) In-Reply-To: <43DE6A09.2040602@redhat.com> References: <43DE4707.9010900@feuerpokemon.de> <43DE6A09.2040602@redhat.com> Message-ID: <43DF869C.1090700@feuerpokemon.de> Daniel J Walsh wrote: > dragoran wrote: > >> Hello. >> I am working on selinux support in initng, which is in review for >> extras now [1]. >> But it seems that initng requires a policy to work (just tested in >> targeted mode) >> Using the default context (sbin_t) lets all apps that are started >> from initng run as kernel_t. > > What is the path? We can set it up in policy. >> Relabling /sbin/initng to init_exec_t (same as init) fixes this and >> the processes run as init_t and udev_t for udev, but some issues >> still remain. > > I will add to policy. ok thx >> hald,httpd, etc. also run as init_t which is *wrong* they have to get >> into their own domain. How is this handled in sysvinit? >> After reading the code I havn't found anything about it. > > Are the startup scripts marked initrc_exec_t? > > yes I did chcon -t initrc_exec_t on all files in /etc/initng/system and /etc/initng/daemons >> The patch I wrote can be found here: >> http://bugzilla.initng.thinktux.net/show_bug.cgi?id=365 >> Did I do something wrong? Did I miss something? >> After fixing this we will run into an other problem. Every time the >> filesystem gots relabled initng will become sbin_t which will break it. >> To fix this we need to modify the selinux-policy. What should be done >> if a package in extras requires to change a core package? >> Should I just fill a bug against it and hope that it will be released >> as an update for FC4, and gets into rawhide too? >> Was unable to find anything about it in the wiki. >> 1: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > From dragoran at feuerpokemon.de Tue Jan 31 16:50:13 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 31 Jan 2006 17:50:13 +0100 Subject: mono (beagle) + execmem In-Reply-To: <43DE6A39.1070301@redhat.com> References: <43DE5B66.8030902@feuerpokemon.de> <43DE6A39.1070301@redhat.com> Message-ID: <43DF9545.8030205@feuerpokemon.de> Daniel J Walsh schrieb: > dragoran wrote: > >> it seems that beagle/mono requires execmem but this is disabled in >> the policy for them? >> is this a known bug or should I fill it? >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Mono is supposed to be allowed execmem? Check the labeleing on the > executable. Should be mono_exec_t. > > ok did that and it works now. can we make this one dontaudit? it floodes the logfiles with granted messages which makes it harder to read them... From dragoran at feuerpokemon.de Tue Jan 31 17:50:53 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 31 Jan 2006 18:50:53 +0100 Subject: mono (beagle) + execmem In-Reply-To: <43DF9545.8030205@feuerpokemon.de> References: <43DE5B66.8030902@feuerpokemon.de> <43DE6A39.1070301@redhat.com> <43DF9545.8030205@feuerpokemon.de> Message-ID: <43DFA37D.9050601@feuerpokemon.de> dragoran wrote: > Daniel J Walsh schrieb: > >> dragoran wrote: >> >>> it seems that beagle/mono requires execmem but this is disabled in >>> the policy for them? >>> is this a known bug or should I fill it? >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> >> Mono is supposed to be allowed execmem? Check the labeleing on the >> executable. Should be mono_exec_t. >> >> > ok did that and it works now. > can we make this one dontaudit? > it floodes the logfiles with granted messages which makes it harder to > read them... > same for gij would it be possible to have atleast a boolean that prevents the granted messages for execmem? From justin at jdjlab.com Tue Jan 31 18:24:37 2006 From: justin at jdjlab.com (Justin Willmert) Date: Tue, 31 Jan 2006 12:24:37 -0600 (CST) Subject: Spamassassin emails have wrong perms -- CC'ed to selinux list]] Message-ID: <39141.207.32.3.5.1138731877.squirrel@www.jdjlab.com> Justin Willmert wrote: > Paul Howarth wrote: >> On Sun, 2006-01-29 at 22:52 -0600, Justin Willmert wrote: >>> Ivan Gyurdiev wrote: >>>>> I'm cc-ing this to the fedora-selinux-list. I think some of the >>>>> problems may be applicable there. >>>>> >>>>> OK, after some more testing, when I disable SELinux, many of the >>>>> errors go away. First of all, I get rid of the error message >>>>> saying user can not be found and with it the 'still running as >>>>> root' error. Second, it is able to access the bayes_journal file >>>>> (as long as normal unix permissions are right, which I've figured >>>>> out). So I guess the problem is an SELinux issue which I can't >>>>> solve. I'd attach some avc error messages, but I can't seem to >>>>> find any. I've looked in maillog, secure, and messages, but nothing. >>>> Have you looked in the audit log, where all such messages are >>>> usually found ? >>>> /var/log/audit.log >>>> >>> Below is what showed up in audit/audit.log when I sent a message >>> through >>> spamassassin. I'm _*really*_ rusty on SELinux...it's the one thing I >>> have to deal with quite often that I haven't been able to learn how to >>> use...it's so foreign to me. I've never looked in audit.log before: the >>> avc messages used to show up in messages, but now as far back as my >>> logs >>> go, I don't have a single avc message. This all looks like jibberish to >>> me, so I need your guy's help. >>> >>> Thanks, >>> Justin >>> >>> type=AVC msg=audit(1138596151.681:104174): avc: denied { >>> name_connect } for pid=23796 comm="spamd" dest=389 >>> scontext=root:system_r:spamd_t >>> tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket >>> < clipped > >> >> Are you using LDAP for authentication or to handle mail accounts? >> >> Paul. > No, I am not using LDAP in spamassassin itself (there are ldap > arguments to spamd and I'm not using those), but my system uses LDAP > authentication through nsswitch/pam (whatever the distinction is). > Does spamd need to know my ldap server's information? > > I believe I found a temporary work around for the bayes files: I put > them in a non-standard location (/etc/mail/bayes/) because I wanted a > system-wide database (some users don't get enough spam to warrant > their own database). I found if I set /etc/mail/bayes/ to > user_home_dir_t and /etc/mail/bayes/* to user_home_t that the denied > messages for files are gone (if I'm reading the logs right). I don't > see the file denial messages in the log output I put above, but they > are in audit.log and in the latest test, they aren't there so I'm > hoping I'm looking into all of this right. If you want me to confirm > all of this, I can reset the directory context and do some tests, then > set up the directory context again and compare that result, somebody > just has to ask. > Now I've just got to solve the LDAP messages. I'll try to look into > this a bit, but I'm probably going to need the help, so thanks to all > those who take time to reply. > > Justin > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > I've got a question about how SELinux works underneath. I'm doing a lot of speculating based on the few things I think I know, so correct me when I'm wrong. When SpamAssassin wants to get the user information, it probably uses a system call that is controlled through /etc/nsswitch.conf (I've seen the call before, but can't think of it off the top of my head). That in turn would connect to my LDAP server and authenticate the user and download its profile information. The nsswitch libraries would be in SpamAssassin's process space (if I understand linux programming correctly), so that would mean that if SpamAssassin is under an SELinux context, then the nsswitch libraries would be too. Would this be where I'm getting denied messages for ldap_port_t messages from? If I've thought this through correctly and this is a problem, would somebody tell me so that I can post a bugzilla report? I'll search bugzilla later to make sure that it's not already in there (I've got to go to school so I don't really have time to do it right now). Thanks to all those who've helped! Justin -- fedora-list mailing list fedora-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list From kcarr at tresys.com Tue Jan 31 18:31:38 2006 From: kcarr at tresys.com (Kevin Carr) Date: Tue, 31 Jan 2006 13:31:38 -0500 Subject: ANN: Setools-2.3 release Message-ID: <200601311831.k0VIVcNq002297@gotham.columbia.tresys.com> Setools-2.3 is now available on the Tresys Technology website. http://tresys.com/selinux/selinux_policy_tools.shtml This version adds MLS and OCONS to apol and seinfo as well as some other smaller changes throughout the tools. Here is the detailed changelog. apol: added new MLS components tab for sensitivities, levels, and categories. Changed users tab to support ranges and default levels. added range transition tab for searching range Transition rules. added new tab for network context components. added new tab for file system context components. libapol: added binpol support for MLS, network contexts, and file system contexts. seinfo: added command line options for MLS components. added command line options for network contexts and file system contexts. sesearch: added command line option for searching for rules by conditional boolean name. seaudit: added new column in the log view for the 'comm' field found in auditd log files. added filters for the 'comm' field and 'message' field. manpages: added manpages for all tools. Kevin Carr Tresys Technology 410.290.1411 x137 From d.rye at roadtech.co.uk Tue Jan 31 18:40:49 2006 From: d.rye at roadtech.co.uk (David Rye) Date: Tue, 31 Jan 2006 18:40:49 +0000 Subject: Problems with snmpd following update. Message-ID: <43DFAF31.161398D@roadtech.co.uk> Have run in to a problem on a couple of servers that I have updated in the last week or so. snmpd does not start after a reboot, the following log extract is from /var/log/messages on server f4. Jan 31 17:26:54 f4 acpid: acpid startup succeeded Jan 31 17:26:54 f4 kernel: audit(1138728414.530:2): avc: denied { execmem } fo r pid=5278 comm="snmpd" scontext=user_u:system_r:snmpd_t tcontext=user_u:system _r:snmpd_t tclass=process Jan 31 17:26:54 f4 snmpd: /usr/sbin/snmpd: error while loading shared libraries: libbeecrypt.so.6: cannot enable executable stack as shared object requires: Per mission denied Jan 31 17:26:54 f4 snmpd: snmpd startup failed Running execstack -q /usr/lib/libbeecrypt.so.6 gives X /usr/lib/libbeecrypt.so.6 So the library is explisitly marked as requiring an executable stack. looking at the obvious rpms yields the following kernel-2.6.12-1.1381_FC3 was kernel-2.6.11-1.14_FC3 net-snmp-5.2.1.2-FC3.1 unchanged net-snmp-libs-5.2.1.2-FC3.1 unchanged selinux-policy-targeted-1.17.30-3.19 was selinux-policy-targeted-1.17.30-2.96 libselinux-1.19.1-8 unchanged beecrypt-3.1.0-6 unchanged Any suggestions appreciated. -- J. David Rye http://www.roadrunner.uk.com http://www.rha.org.uk mailto://d.rye at roadtech.co.uk From tscherf at redhat.com Tue Jan 31 19:49:14 2006 From: tscherf at redhat.com (Thorsten Scherf) Date: Tue, 31 Jan 2006 20:49:14 +0100 Subject: user mapping Message-ID: <43DFBF3A.90203@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 general question: I have a Unix user called "foo" which I would like to map to the SELinux User Identity "bar_u". In which file must I define this mapping, so that every time the user "foo" logs in, the context is set to "bar_u:[user_r_user_t]"?! Thanks, Thorsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD3786wfkoLTuSgLsRAnOeAKD5oEejeLDKy2f3jsxjnty8uB7abACg8Ysk VNN2B9+3sGwpjGnmf3utQx0= =eW75 -----END PGP SIGNATURE----- From dwalsh at redhat.com Tue Jan 31 20:09:48 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 31 Jan 2006 15:09:48 -0500 Subject: SELinux Wiki is open for business... Message-ID: <43DFC40C.3040207@redhat.com> www.fedoraproject.org/wiki/SELinux is open. If you want to make changes to these pages and add your own content you need to make a new account and to send kwade at redhat.com a request to get added to EditGroup or ask on on #fedora-websites on freenode, if they want faster service I am attempting to dump some information there, also. Any input is appreciated. Dan From dwalsh at redhat.com Tue Jan 31 21:25:27 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 31 Jan 2006 16:25:27 -0500 Subject: Problem with interbase (firebird-1.5) on FC4 box, httpd-2.0.54, php-interbase-5.0.4-10.5 In-Reply-To: <200601301639.21188.dpaul@gmx.net> References: <200601301639.21188.dpaul@gmx.net> Message-ID: <43DFD5C7.4080901@redhat.com> Daniel Paul wrote: > Hello there, > > because I need interbase (firebird) support in php, I recompiled the actual > php-5.0.4-10.5 package with interbase support (--with-interbase=shared). When > I start httpd there is the following message in error_log: > > PHP Warning: PHP Startup: Unable to load dynamic library > '/usr/lib/php/modules/interbase.so' - object requires: cannot enable > executable stack as shared object requires: Permission denied in Unknown on > line 0 > try execstack -c /usr/lib/php/modules/interbase.so execstack is a security problem http://people.redhat.com/drepper/selinux-mem.html > phpinfo() shows that php has read the interbase.ini file which contains a > reference to the interbase.so module, but interbase support is disabled > (nothing shows up regarding interbase). With selinux set to permissive mode > (instead of enforcing), there is no such message and phpinfo() shows me, that > interbase support is enabled. > > audit.log shows the following: > > type=AVC msg=audit(1138630853.033:10): avc: denied { execstack } for > pid=1886 comm="httpd" scontext=root:system_r:httpd_t > tcontext=root:system_r:httpd_t tclass=process > type=SYSCALL msg=audit(1138630853.033:10): arch=40000003 syscall=125 > success=no exit=-13 a0=bf8a3000 a1=1000 a2=1000007 a3=d5a000 items=0 pid=1886 > auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd" > exe="/usr/sbin/httpd" > > Any help would be truly appreciated. > > Thanks in advance, > > Daniel > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From dwalsh at redhat.com Tue Jan 31 21:46:22 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 31 Jan 2006 16:46:22 -0500 Subject: SElinux and firestarter In-Reply-To: <645d17210601290803u3a931d1fg@mail.gmail.com> References: <645d17210601290803u3a931d1fg@mail.gmail.com> Message-ID: <43DFDAAE.1090405@redhat.com> Jonathan Underwood wrote: > Hi, > > There appears to be issues with SElinux and the firestarter package > available from fedora-extras. I have attached the errors from > /var/log/messages upon boot to this email. I suspect it may be related > to either dhcpd or kernel module loading upon boot, but I'm rather > clueless about SElinux. If someone could give me some pointers on how > to proceed with debugging this it would be really appreciated. I have > reported the bug here: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179248 > > This is with kernel 2.6.14-1.1656_FC4, libselinux-1.23.10-2, > selinux-policy-targeted-1.27.1-2.16. > > I realize that I have probably not given enough information to debug > this, but I am not sure what else would be useful. > > Many thanks, > Jonathan > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Looks like the problem here is hooking the dhclient program. This causes the firestarter script to run in dhclient mode, and dhclient is not allowed to do modutil and iptables. From dwalsh at redhat.com Tue Jan 31 21:50:54 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 31 Jan 2006 16:50:54 -0500 Subject: Nagios nrpe and sudo In-Reply-To: <1138710643.7076.240.camel@moss-spartans.epoch.ncsc.mil> References: <1138486860.11412.21.camel@avenin.ebourne.me.uk> <1138634883.7076.48.camel@moss-spartans.epoch.ncsc.mil> <1138659082.6632.3.camel@avenin.ebourne.me.uk> <1138659571.6632.5.camel@avenin.ebourne.me.uk> <1138709527.7076.226.camel@moss-spartans.epoch.ncsc.mil> <1138710643.7076.240.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <43DFDBBE.3090905@redhat.com> Stephen Smalley wrote: > On Tue, 2006-01-31 at 07:12 -0500, Stephen Smalley wrote: > >> On Mon, 2006-01-30 at 22:19 +0000, Martin Ebourne wrote: >> >>> Further to this, I note that I don't even need the >>> inetd_child_disable_trans boolean set now. By default nrpe running under >>> xinetd is allowed to sudo. Should this not be controlled? >>> >>> What protection does running xinetd under selinux give? >>> >> IIRC, the default targeted policy in Fedora leaves inetd children who do >> not have a specific domain defined for them unconfined, as otherwise all >> external (outside of Fedora) inetd-based services that lack policy would >> immediately break. The strict policy takes the more conservative >> approach for security, at the risk of greater application breakage. >> > > Ah, sorry, but your point was that nrpe should be confined since it has > policy. However, it appears that the nagios and nrpe policies aren't > being built as part of the Fedora policy at present. > > Those would be good candidates for loadable modules.