From dwalsh at redhat.com Wed Feb 1 02:43:39 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 31 Jan 2006 21:43:39 -0500 Subject: Problems with snmpd following update. In-Reply-To: <43DFAF31.161398D@roadtech.co.uk> References: <43DFAF31.161398D@roadtech.co.uk> Message-ID: <43E0205B.9030709@redhat.com> David Rye wrote: > 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 > > > > Does it work if you execstack -c /usr/lib/libbeecrypt.so.6 > 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. > > From SeLinux at Compucenter.org Wed Feb 1 08:12:45 2006 From: SeLinux at Compucenter.org (G Jahchan) Date: Wed, 1 Feb 2006 10:12:45 +0200 Subject: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16 In-Reply-To: <1138635050.7076.52.camel@moss-spartans.epoch.ncsc.mil> Message-ID: I have upgraded the kernel to 2.6.14-1.1656 and pam to 0.79.9 (from 2.6.14-1.1653 & 0.79.8 respectively) and I am back to the drawing board. Authentication is no longer possible when in enforcing mode, but this time there are NO reported 'avc: denied' messages in any of the logs. The problem may not lie strictly with selinux, as even when in permissive mode, the first authentication attempt to a console always fails, but the second works (with the exact same credentials). Ditto when sudoing a command that requires authentication: never works the first time if in permissive mode, and not at all if in enforcing mode. su on the other hand always works in permissive mode, but never in enforcing mode. When in KDE, a locked station cannot be unlocked, regardless of the status of selinux - permissive or enforcing, it makes no difference. -----Original Message----- From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list-bounces at redhat.com]On Behalf Of Stephen Smalley Sent: Monday, January 30, 2006 17:31 To: G Jahchan Cc: Fedora SE Linux List Subject: RE: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16 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 -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list From maschino at jouy.inra.fr Wed Feb 1 08:31:16 2006 From: maschino at jouy.inra.fr (Emeric Maschino) Date: Wed, 01 Feb 2006 09:31:16 +0100 Subject: Denied { search } mingetty and can't log in In-Reply-To: <1138612818.29923.14.camel@localhost.localdomain> References: <1136886574.5079.29.camel@localhost.localdomain> <1137432900.29976.24.camel@localhost.localdomain> <1138354247.5060.8.camel@localhost.localdomain> <1138612818.29923.14.camel@localhost.localdomain> Message-ID: <1138782677.5061.10.camel@localhost.localdomain> Hi, > 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: Just to inform you that these AVCs have been corrected in selinux- policy-targeted 2.2.9-1. But new hid2hci denied read and write AVCs have appeared. The never-ending game ;-) Cheers, ?meric From ivg2 at cornell.edu Wed Feb 1 08:48:38 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Wed, 01 Feb 2006 03:48:38 -0500 Subject: Denied { search } mingetty and can't log in In-Reply-To: <1138782677.5061.10.camel@localhost.localdomain> References: <1136886574.5079.29.camel@localhost.localdomain> <1137432900.29976.24.camel@localhost.localdomain> <1138354247.5060.8.camel@localhost.localdomain> <1138612818.29923.14.camel@localhost.localdomain> <1138782677.5061.10.camel@localhost.localdomain> Message-ID: <43E075E6.7090200@cornell.edu> > > Just to inform you that these AVCs have been corrected in selinux- > policy-targeted 2.2.9-1. But new hid2hci denied read and write AVCs have > appeared. The never-ending game ;-) > There is no way for this game to end... Not until software developers take over the task of writing policy themselves. I know Dan disagrees with me on this, but I think that this is the only way for selinux to be really accepted into the mainstream. First, however, more infrastructure is needed to make this possible. Modular policy is a step in the right direction. I see that the current strict policy is now modular, and that's good news... From jonathan.underwood at gmail.com Wed Feb 1 12:00:03 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 1 Feb 2006 12:00:03 +0000 Subject: SElinux and firestarter In-Reply-To: <43DFDAAE.1090405@redhat.com> References: <645d17210601290803u3a931d1fg@mail.gmail.com> <43DFDAAE.1090405@redhat.com> Message-ID: <645d17210602010400seae343en@mail.gmail.com> On 31/01/06, Daniel J Walsh wrote: > 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. So what would be the correct approach to remedying this? Change to SElinux policy for dhclient? Request that firestarter change to not run in dhclient mode? Presumably the latter would require a new policy to be written for firestarter? TIA, Jonathan From sds at tycho.nsa.gov Wed Feb 1 12:25:22 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 01 Feb 2006 07:25:22 -0500 Subject: user mapping In-Reply-To: <43DFBF3A.90203@redhat.com> References: <43DFBF3A.90203@redhat.com> Message-ID: <1138796722.18268.10.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-01-31 at 20:49 +0100, Thorsten Scherf wrote: > -----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]"?! In rawhide/FC5, you would use semanage(8) to configure the /etc/selinux/$SELINUXTYPE/seusers file (where SELINUXTYPE is defined by /etc/selinux/config and is targeted by default in Fedora). Like this: /usr/sbin/semanage login -a -s bar_u foo Then to list the current settings, /usr/sbin/semanage login -l This manipulates the seusers file in the module store and then regenerates the installed file; don't edit that file directly. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Feb 1 12:59:49 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 01 Feb 2006 07:59:49 -0500 Subject: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16 In-Reply-To: References: Message-ID: <1138798789.18268.24.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-02-01 at 10:12 +0200, G Jahchan wrote: > I have upgraded the kernel to 2.6.14-1.1656 and pam to 0.79.9 (from > 2.6.14-1.1653 & 0.79.8 respectively) and I am back to the drawing board. > > Authentication is no longer possible when in enforcing mode, but this time > there are NO reported 'avc: denied' messages in any of the logs. > > The problem may not lie strictly with selinux, as even when in permissive mode, > the first authentication attempt to a console always fails, but the second > works (with the exact same credentials). Ditto when sudoing a command that > requires authentication: never works the first time if in permissive mode, and > not at all if in enforcing mode. su on the other hand always works in > permissive mode, but never in enforcing mode. > > When in KDE, a locked station cannot be unlocked, regardless of the status of > selinux - permissive or enforcing, it makes no difference. Any other SELinux messages there? Look for SELINUX_ERR (or use /sbin/ausearch -m selinux_err). Turn on full auditing by SELinux: cd /etc/selinux/strict/src/policy make clean enableaudit load make clean load That will yield a lot of noise in the logs, but you might find something useful. Other possibility is that you are running into an audit_write or audit_control capability denial from the kernel audit subsystem; those aren't audited presently by SELinux since they occur in receiver context. Need to make sure that login and friends have those capabilities. But it looks like they are there in the FC4 strict policy (indirectly via authentication_domain(auth_chkpwd)). -- Stephen Smalley National Security Agency From dwalsh at redhat.com Wed Feb 1 13:09:15 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 01 Feb 2006 08:09:15 -0500 Subject: Denied { search } mingetty and can't log in In-Reply-To: <43E075E6.7090200@cornell.edu> References: <1136886574.5079.29.camel@localhost.localdomain> <1137432900.29976.24.camel@localhost.localdomain> <1138354247.5060.8.camel@localhost.localdomain> <1138612818.29923.14.camel@localhost.localdomain> <1138782677.5061.10.camel@localhost.localdomain> <43E075E6.7090200@cornell.edu> Message-ID: <43E0B2FB.4070202@redhat.com> Ivan Gyurdiev wrote: > >> >> Just to inform you that these AVCs have been corrected in selinux- >> policy-targeted 2.2.9-1. But new hid2hci denied read and write AVCs have >> appeared. The never-ending game ;-) >> > There is no way for this game to end... Not until software developers > take over the task of writing policy themselves. > Hopefully after we release FC5 the number of AVC will decrease steadily as they did in FC3/FC4. The problem now is the volume of change in rawhide and the number of people testing it have not revealed all of the problems. Keep submitting the AVC's, or even better patches and we will keep updating policy. > I know Dan disagrees with me on this, but I think that this is the > only way for selinux to be really accepted into the mainstream.t I don't disagree with you, I would love to have the applications developers to take over the maintenance of policy for their applications. The problem is the developers have different goals then people concerned with security. They want their applications to run, and might take short cuts with security policy. So if they come up against an execmem failure or the inability to read /etc/shadow. Would they redesign the application or just write policy to allow them to do the task they want to do. > First, however, more infrastructure is needed to make this possible. > Modular policy is a step in the right direction. I see that the > current strict policy is now modular, and that's good news... Loadable Modules is the first step. Now we need tools to allow them to write the policy more easily. The current audit2allow allows them to build a policy module out of AVC messages, a step forward would be to add some kind of pattern matching to the tool to figure out what file contexts it might need. IE the domain wants to write to var_run, so it probably needs to use the pid functions in reference policy. I know Mitre/Tresys are looking into tools to make this easier. > > > -- > 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 Feb 1 13:58:27 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 01 Feb 2006 08:58:27 -0500 Subject: SElinux and firestarter In-Reply-To: <645d17210602010400seae343en@mail.gmail.com> References: <645d17210601290803u3a931d1fg@mail.gmail.com> <43DFDAAE.1090405@redhat.com> <645d17210602010400seae343en@mail.gmail.com> Message-ID: <43E0BE83.4050000@redhat.com> Jonathan Underwood wrote: > On 31/01/06, Daniel J Walsh wrote: > >> 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. >> > > So what would be the correct approach to remedying this? Change to > SElinux policy for dhclient? Request that firestarter change to not > run in dhclient mode? That would be my preference. > Presumably the latter would require a new policy > to be written for firestarter? > You could write a new policy for firestarter which dhclient could transition to. Giving these privs to dhclient would be very dangerous. > TIA, > Jonathan > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From d.rye at roadtech.co.uk Wed Feb 1 18:54:43 2006 From: d.rye at roadtech.co.uk (David Rye) Date: Wed, 01 Feb 2006 18:54:43 +0000 Subject: Problems with snmpd following update. References: <43DFAF31.161398D@roadtech.co.uk> Message-ID: <43E103F3.6E6C0D6F@roadtech.co.uk> David Rye wrote: > > 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 > setenforce 0 service snmpd start setenforce 1 Starts snmpd but logs 3 policy violations Feb 1 13:54:47 f4 kernel: audit(1138802087.074:6): avc: denied { execmem } for pid=8464 comm="snmpd" scontext=root:system_r:snmpd_t tcontext=root:system_r:snmpd_t tclass=process Feb 1 13:54:47 f4 kernel: audit(1138802087.099:7): avc: denied { read } for pid=8464 comm="snmpd" name="config" dev=dm-0 ino=13320608 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:selinux_config_t tclass=file Feb 1 13:54:47 f4 kernel: audit(1138802087.099:8): avc: denied { getattr } for pid=8464 comm="snmpd" name="config" dev=dm-0 ino=13320608 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:selinux_config_t tclass=file Note inode 13320608 is /etc/selinux/config ls -Z /usr/sbin/snmpd -rwxr-xr-x root root system_u:object_r:snmpd_exec_t /usr/sbin/snmpd Which on my limited understanding looks correct and I think means that snmpd executes with a custom policy indicated by the snmpd_exec_t bit. Does this mean that there is a bug in the policy for snmpd defined by the rpm selinux-policy-targeted-1.17.30-3.19 ? -- J. David Rye http://www.roadrunner.uk.com http://www.rha.org.uk mailto://d.rye at roadtech.co.uk From sds at tycho.nsa.gov Wed Feb 1 19:13:09 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 01 Feb 2006 14:13:09 -0500 Subject: Problems with snmpd following update. In-Reply-To: <43E103F3.6E6C0D6F@roadtech.co.uk> References: <43DFAF31.161398D@roadtech.co.uk> <43E103F3.6E6C0D6F@roadtech.co.uk> Message-ID: <1138821189.18268.72.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-02-01 at 18:54 +0000, David Rye wrote: > Which on my limited understanding looks correct and I think means that > snmpd executes with a > custom policy indicated by the snmpd_exec_t bit. > > Does this mean that there is a bug in the policy for snmpd defined by > the rpm > selinux-policy-targeted-1.17.30-3.19 ? No, it means that libbeecrypt.so.6 is incorrectly marked by the toolchain as requiring an executable stack. This was corrected in FC4. Use execstack -c to clear the marking to avoid triggering an executable stack there so that you don't have to allow it in policy (which would expose you to risk). The /etc/selinux/config denials are just noise; libselinux always tries to open it from constructor, so any program that happens to link with it triggers attempts there, which are normally silenced in enforcing mode by dontaudit rules. -- Stephen Smalley National Security Agency From d.rye at roadtech.co.uk Wed Feb 1 19:20:28 2006 From: d.rye at roadtech.co.uk (David Rye) Date: Wed, 01 Feb 2006 19:20:28 +0000 Subject: Problems with snmpd following update. References: <43DFAF31.161398D@roadtech.co.uk> <43E0205B.9030709@redhat.com> Message-ID: <43E109FC.46618FAB@roadtech.co.uk> Daniel J Walsh wrote: > > David Rye wrote: > > 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 > > > > > > > > > Does it work if you > execstack -c /usr/lib/libbeecrypt.so.6 Yes and no. snmpd starts but the following entery is added to /var/log/messages Feb 1 18:31:48 workstation1 kernel: audit(1138818708.669:5): avc: denied { search } for pid=3176 comm="snmpd" scontext=root:system_r:snmpd_t tcontext=system_u:object_r:sysctl_dev_t tclass=dir snmpwalk will then display the mib tree or at any rate most of it. However while running snmpwalk 9000 additional avc: eneries were added to /var/log/messages. Feb 1 18:37:33 workstation1 kernel: audit(1138819053.932:7): avc: denied { signull } for pid=3285 comm="snmpd" scontext=root:system_r:snmpd_t tcontext=root:system_r:unconfined_t tclass=process Feb 1 18:37:33 workstation1 kernel: audit(1138819053.932:8): avc: denied { signull } for pid=3285 comm="snmpd" scontext=root:system_r:snmpd_t tcontext=root:system_r:unconfined_t tclass=process Feb 1 18:37:33 workstation1 kernel: audit(1138819053.932:9): avc: denied { signull } for pid=3285 comm="snmpd" scontext=root:system_r:snmpd_t tcontext=root:system_r:unconfined_t tclass=process Feb 1 18:37:33 workstation1 kernel: audit(1138819053.932:10): avc: denied { signull } for pid=3285 comm="snmpd" scontext=root:system_r:snmpd_t tcontext=root:system_r:unconfined_t tclass=process Feb 1 18:37:33 workstation1 kernel: audit(1138819053.932:11): avc: denied { signull } for pid=3285 comm="snmpd" scontext=root:system_r:snmpd_t tcontext=root:system_r:unconfined_t tclass=process Feb 1 18:37:33 workstation1 kernel: audit(1138819053.932:12): avc: denied { signull } for pid=3285 comm="snmpd" scontext=root:system_r:snmpd_t tcontext=root:system_r:unconfined_t tclass=process Feb 1 18:37:33 workstation1 kernel: audit(1138819053.932:13): avc: denied { signull } for pid=3285 comm="snmpd" scontext=root:system_r:snmpd_t tcontext=root:system_r:unconfined_t tclass=process Feb 1 18:37:33 workstation1 kernel: audit(1138819053.932:14): avc: denied { signull } for pid=3285 comm="snmpd" scontext=root:system_r:snmpd_t tcontext=root:system_r:unconfined_t tclass=process Feb 1 18:37:33 workstation1 kernel: audit(1138819053.956:15): avc: denied { getattr } for pid=3285 comm="snmpd" name="/" dev=usbfs ino=1392 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:usbfs_t tclass=dir Feb 1 18:37:33 workstation1 kernel: audit(1138819053.962:16): avc: denied { getattr } for pid=3285 comm="snmpd" name="/" dev=hda1 ino=2 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:boot_t tclass=dir Feb 1 18:37:34 workstation1 kernel: audit(1138819054.000:17): avc: denied { getattr } for pid=3285 comm="snmpd" name="/" dev=usbfs ino=1392 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:usbfs_t tclass=dir Feb 1 18:37:34 workstation1 kernel: audit(1138819054.002:18): avc: denied { getattr } for pid=3285 comm="snmpd" name="/" dev=hda1 ino=2 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:boot_t tclass=dir Feb 1 18:37:34 workstation1 kernel: audit(1138819054.018:19): avc: denied { getattr } for pid=3285 comm="snmpd" name="/" dev=usbfs ino=1392 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:usbfs_t tclass=dir Feb 1 18:37:34 workstation1 kernel: audit(1138819054.020:20): avc: denied { getattr } for pid=3285 comm="snmpd" name="/" dev=hda1 ino=2 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:boot_t tclass=dir Feb 1 18:37:34 workstation1 kernel: audit(1138819054.035:21): avc: denied { getattr } for pid=3285 comm="snmpd" name="/" dev=usbfs ino=1392 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:usbfs_t tclass=dir Feb 1 18:37:34 workstation1 kernel: audit(1138819054.055:22): avc: denied { getattr } for pid=3285 comm="snmpd" name="/" dev=hda1 ino=2 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:boot_t tclass=dir Feb 1 18:37:34 workstation1 kernel: audit(1138819054.071:23): avc: denied { getattr } for pid=3285 comm="snmpd" name="/" dev=usbfs ino=1392 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:usbfs_t tclass=dir Feb 1 18:37:34 workstation1 kernel: audit(1138819054.073:24): avc: denied { getattr } for pid=3285 comm="snmpd" name="/" dev=hda1 ino=2 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:boot_t tclass=dir Feb 1 18:37:34 workstation1 kernel: audit(1138819054.092:25): avc: denied { getattr } for pid=3285 comm="snmpd" name="/" dev=usbfs ino=1392 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:usbfs_t tclass=dir Feb 1 18:37:34 workstation1 kernel: audit(1138819054.095:26): avc: denied { getattr } for pid=3285 comm="snmpd" name="/" dev=hda1 ino=2 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:boot_t tclass=dir Feb 1 18:37:34 workstation1 kernel: audit(1138819054.111:27): avc: denied { getattr } for pid=3285 comm="snmpd" name="/" dev=usbfs ino=1392 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:usbfs_t tclass=dir Feb 1 18:37:34 workstation1 kernel: audit(1138819054.111:28): avc: denied { getattr } for pid=3285 comm="snmpd" name="/" dev=hda1 ino=2 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:boot_t tclass=dir Feb 1 18:37:36 workstation1 kernel: audit(1138819056.112:29): avc: denied { getattr } for pid=3285 comm="snmpd" name="tmp" dev=hda2 ino=9895940 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:tmp_t tclass=dir Feb 1 18:37:36 workstation1 kernel: audit(1138819056.135:30): avc: denied { read } for pid=3285 comm="snmpd" name="tmp" dev=hda2 ino=3915910 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:usr_t tclass=lnk_file Feb 1 18:37:36 workstation1 kernel: audit(1138819056.135:31): avc: denied { getattr } for pid=3285 comm="snmpd" name="tmp" dev=hda2 ino=4374529 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:tmp_t tclass=dir Feb 1 18:37:42 workstation1 kernel: audit(1138819062.738:32): avc: denied { getattr } for pid=3285 comm="snmpd" name="tmp" dev=hda2 ino=9895940 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:tmp_t tclass=dir Feb 1 18:37:42 workstation1 kernel: audit(1138819062.738:33): avc: denied { read } for pid=3285 comm="snmpd" name="tmp" dev=hda2 ino=3915910 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:usr_t tclass=lnk_file Feb 1 18:37:42 workstation1 kernel: audit(1138819062.738:34): avc: denied { getattr } for pid=3285 comm="snmpd" name="tmp" dev=hda2 ino=4374529 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:tmp_t tclass=dir Feb 1 18:37:44 workstation1 kernel: audit(1138819063.999:35): avc: denied { getattr } for pid=3285 comm="snmpd" name="tmp" dev=hda2 ino=9895940 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:tmp_t tclass=dir Feb 1 18:37:44 workstation1 kernel: audit(1138819063.999:36): avc: denied { read } for pid=3285 comm="snmpd" name="tmp" dev=hda2 ino=3915910 scontext=root:system_r:snmpd_t tcontext=system_u:object_r:usr_t tclass=lnk_file ------snip another 6000 odd lines all getattr or read on file tmp---- inode 3915910 sym link /usr/tmp to /var/tmp 4374529 /tmp 9895940 /var/tmp > > 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 sds at tycho.nsa.gov Wed Feb 1 19:39:37 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 01 Feb 2006 14:39:37 -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: <1138822777.18268.82.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-01-26 at 13:02 -0500, 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? Looks like the .spec file needs to install all of the modules as a single transaction to deal with mutually dependent modules. Or, it could install them layer-by-layer. Unfortunately, current semodule usage requires you to generate the list of all the modules, then prefix them all with -i options, then pass that entire string as the commandline to semodule. Something like: # Location where modules are installed from policy package cd /usr/share/selinux/strict # Generate semodule command line with all non-base modules ls *.pp | sed -e "/base.pp/d" -e "/enableaudit.pp/d" -e "i-i " | tr "\n" " " > out # Run semodule semodule -v `cat out` -- Stephen Smalley National Security Agency From justin at jdjlab.com Wed Feb 1 23:12:46 2006 From: justin at jdjlab.com (Justin Willmert) Date: Wed, 01 Feb 2006 17:12:46 -0600 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: <43E1406E.8020603@jdjlab.com> I said I'd post my final results, so here they are. All these problems are describing spamd and not the spamassassin program on FC4. The problems only affect spamd because it is subject to selinux policy effects where spamassassin (run by a user) isn't (at least in the targeted policy). My first problem was with emails being owned by root instead of the correct user. I am using /etc/procmailrc rather than ~/.procmailrc, so it would by default be under root permissions. I added the line 'DROPPRIV=yes' to make it have user permissions instead, but I mistyped it. It should be 'DROPPRIVS=yes'. *Notice the added S*. That was all there was to that problem. Human error. Next, I set up spamassassin to share a common bayes database. Even with nobody(99) owning it (that's what spamassassin would setuid to after failing to setuid to the user. More on that below...), I still couldn't write to the database. After looking through the selinux policy source files for spamassassin (you can surprisingly learn a lot just by looking through those files...), I found that the bayes files should probably have a user_home_t context, and the folder they reside in, a context of user_home_dir_t (which makes sense considering they're normally found in a user's home directory). After I had set /etc/mail/bayes/ (the folder I chose to house my bayes files) and it's contents to those contexts, I got rid of that problem. Now for the user problems. All the users on my system are setup in an LDAP directory. My system uses nsswitch.conf mechanisms (set with the authconfig utility), so when spamd went to connect to the ldap server (indirectly through normal linux authentication libraries which behind the scenes connect to the ldap server. Programmers should understand this logic.), selinux would deny access because spamd doesn't have ldap_port_t permissions (or in layman's terms, spamd wasn't allowed to connect to any port but tcp port 783 which is spamd's command port). As of selinux-policy-targeted-1.27.1-2.16, there isn't a fix, but Dan Walsh has told me that he has put it in the rawhide and I've posted a bugzilla report about it, so there should be a fix soon. A perfectly OK temporary fix is to just use the spamassassin executable in your procmail scripts rather than using spamc to communicate to spamd. That's what I'm doing right now and it is working fine (with some performance loss because of program load/unload times, etc). Thanks to all those who have helped. Justin Willmert From dant at cdkkt.com Wed Feb 1 23:17:05 2006 From: dant at cdkkt.com (Daniel B. Thurman) Date: Wed, 1 Feb 2006 15:17:05 -0800 Subject: testing, please ignore Message-ID: -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.14.25/247 - Release Date: 1/31/2006 From dragoran at feuerpokemon.de Thu Feb 2 17:07:24 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 02 Feb 2006 18:07:24 +0100 Subject: extras package that require changes in selinux-policy (initng) In-Reply-To: <43DF869C.1090700@feuerpokemon.de> References: <43DE4707.9010900@feuerpokemon.de> <43DE6A09.2040602@redhat.com> <43DF869C.1090700@feuerpokemon.de> Message-ID: <43E23C4C.4070203@feuerpokemon.de> dragoran schrieb: > 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 > checked this and found out that initng does not execute any scripts. the "scripts" are just files that contain infos about which daemon should be started and which deps it has. this results in hald beeing started directly from initng using execv(). This results in hald (and other services) run as init_t. If I put /sbin/service hald start into the exec line hald runs as hald_t. Why is a script required to get into the correct domain? Is there any way to fix this without adding setexeccon() for every daemon? From Valdis.Kletnieks at vt.edu Thu Feb 2 17:18:08 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 02 Feb 2006 12:18:08 -0500 Subject: rawhide selinux-policy-strict whoopsage... In-Reply-To: Your message of "Wed, 01 Feb 2006 14:39:37 EST." <1138822777.18268.82.camel@moss-spartans.epoch.ncsc.mil> References: <200601261802.k0QI20ga016020@turing-police.cc.vt.edu> <1138822777.18268.82.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200602021718.k12HI819008489@turing-police.cc.vt.edu> On Wed, 01 Feb 2006 14:39:37 EST, Stephen Smalley said: > Looks like the .spec file needs to install all of the modules as a > single transaction to deal with mutually dependent modules. Or, it > could install them layer-by-layer. Unfortunately, current semodule > usage requires you to generate the list of all the modules, then prefix > them all with -i options, then pass that entire string as the > commandline to semodule. Something like: > # Location where modules are installed from policy package > cd /usr/share/selinux/strict > # Generate semodule command line with all non-base modules > ls *.pp | sed -e "/base.pp/d" -e "/enableaudit.pp/d" -e "i-i " | tr "\n " " " > out > # Run semodule > semodule -v `cat out` I did this after yum updated me to selinux-policy-strict-2.2.9-1 this morning, and things are much less broken now. Now we have: Attempting to install module 'acct.pp': Ok: return value of 0. Attempting to install module 'alsa.pp': Ok: return value of 0. Attempting to install module 'amanda.pp': Ok: return value of 0. ... Attempting to install module 'xserver.pp': Ok: return value of 0. Attempting to install module 'zebra.pp': Ok: return value of 0. Committing changes: libsepol.check_assertion_helper: assertion on line 0 violated by allow pam_console_t scsi_generic_device_t:chr_file { setattr }; libsepol.check_assertion_helper: assertion on line 0 violated by allow initrc_t scsi_generic_device_t:chr_file { setattr }; libsepol.check_assertion_helper: assertion on line 0 violated by allow restorecon_t scsi_generic_device_t:chr_file { relabelto }; libsepol.check_assertion_helper: assertion on line 0 violated by allow setfiles_t scsi_generic_device_t:chr_file { relabelto }; libsepol.check_assertion_helper: assertion on line 0 violated by allow restorecon_t lvm_vg_t:chr_file { relabelto }; libsepol.check_assertion_helper: assertion on line 0 violated by allow setfiles_t lvm_vg_t:chr_file { relabelto }; libsepol.check_assertion_helper: assertion on line 0 violated by allow pam_console_t fixed_disk_device_t:blk_file { setattr }; libsepol.check_assertion_helper: assertion on line 0 violated by allow hotplug_t fixed_disk_device_t:blk_file { setattr }; libsepol.check_assertion_helper: assertion on line 0 violated by allow restorecon_t fixed_disk_device_t:chr_file { relabelto }; libsepol.check_assertion_helper: assertion on line 0 violated by allow setfiles_t fixed_disk_device_t:chr_file { relabelto }; libsepol.check_assertion_helper: assertion on line 0 violated by allow initrc_t shadow_t:file { getattr }; libsepol.check_assertion_helper: assertion on line 0 violated by allow locate_t shadow_t:file { getattr }; libsepol.check_assertion_helper: assertion on line 0 violated by allow sysadm_t shadow_t:file { getattr }; libsepol.check_assertion_helper: assertion on line 0 violated by allow prelink_t shadow_t:file { getattr }; libsepol.check_assertion_helper: assertion on line 0 violated by allow nscd_t shadow_t:file { getattr }; libsepol.check_assertion_helper: assertion on line 0 violated by allow system_crond_t shadow_t:file { getattr }; libsepol.check_assertion_helper: assertion on line 0 violated by allow restorecon_t shadow_t:file { getattr relabelto }; libsepol.check_assertion_helper: assertion on line 0 violated by allow setfiles_t shadow_t:file { getattr relabelto }; libsepol.check_assertions: 18 assertion violations occured libsemanage.semanage_expand_sandbox: Expand module failed semodule: Failed! 18 assertions. This looks fixable.... -------------- 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 Thu Feb 2 17:31:08 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 02 Feb 2006 12:31:08 -0500 Subject: rawhide selinux-policy-strict whoopsage... In-Reply-To: <200602021718.k12HI819008489@turing-police.cc.vt.edu> References: <200601261802.k0QI20ga016020@turing-police.cc.vt.edu> <1138822777.18268.82.camel@moss-spartans.epoch.ncsc.mil> <200602021718.k12HI819008489@turing-police.cc.vt.edu> Message-ID: <1138901468.18268.205.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-02-02 at 12:18 -0500, Valdis.Kletnieks at vt.edu wrote: > 18 assertions. This looks fixable.... Yes, that is actually a bug in the copying of assertions during module linking - no real assertions failed. Should be fixed in libsepol 1.11.11. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu Feb 2 17:49:17 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 02 Feb 2006 12:49:17 -0500 Subject: extras package that require changes in selinux-policy (initng) In-Reply-To: <43E23C4C.4070203@feuerpokemon.de> References: <43DE4707.9010900@feuerpokemon.de> <43DE6A09.2040602@redhat.com> <43DF869C.1090700@feuerpokemon.de> <43E23C4C.4070203@feuerpokemon.de> Message-ID: <1138902557.18268.212.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-02-02 at 18:07 +0100, dragoran wrote: > checked this and found out that initng does not execute any scripts. > the "scripts" are just files that contain infos about which daemon > should be started and which deps it has. > this results in hald beeing started directly from initng using execv(). > This results in hald (and other services) run as init_t. If I put > /sbin/service hald start into the exec line hald runs as hald_t. > Why is a script required to get into the correct domain? Is there any > way to fix this without adding setexeccon() for every daemon? The current policy only defines domain transitions from init (init_t) to rc (initrc_t) -> daemons. It doesn't define direct domain transitions from init_t to the daemon domains, except for a few cases where that has been necessary (getty, gdm). The policy could certainly also include additional transitions directly from init_t to the daemon domains, and that would work, but it will bloat the policy a bit to include both sets of transitions. The script isn't required; it just happens to be the current init approach, so that is what policy was written for. Adding setexeccon() to every daemon wouldn't be desirable or helpful. -- Stephen Smalley National Security Agency From dragoran at feuerpokemon.de Thu Feb 2 17:48:36 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 02 Feb 2006 18:48:36 +0100 Subject: extras package that require changes in selinux-policy (initng) In-Reply-To: <1138902557.18268.212.camel@moss-spartans.epoch.ncsc.mil> References: <43DE4707.9010900@feuerpokemon.de> <43DE6A09.2040602@redhat.com> <43DF869C.1090700@feuerpokemon.de> <43E23C4C.4070203@feuerpokemon.de> <1138902557.18268.212.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <43E245F4.30309@feuerpokemon.de> Stephen Smalley wrote: >On Thu, 2006-02-02 at 18:07 +0100, dragoran wrote: > > >>checked this and found out that initng does not execute any scripts. >>the "scripts" are just files that contain infos about which daemon >>should be started and which deps it has. >>this results in hald beeing started directly from initng using execv(). >>This results in hald (and other services) run as init_t. If I put >>/sbin/service hald start into the exec line hald runs as hald_t. >>Why is a script required to get into the correct domain? Is there any >>way to fix this without adding setexeccon() for every daemon? >> >> > >The current policy only defines domain transitions from init (init_t) to >rc (initrc_t) -> daemons. It doesn't define direct domain transitions >from init_t to the daemon domains, except for a few cases where that has >been necessary (getty, gdm). The policy could certainly also include >additional transitions directly from init_t to the daemon domains, and >that would work, but it will bloat the policy a bit to include both sets >of transitions. The script isn't required; it just happens to be the >current init approach, so that is what policy was written for. Adding >setexeccon() to every daemon wouldn't be desirable or helpful. > > > so what is the solution? use setexecon() to run the daemons as initrc_t to let the domain transitions take effect? this should also be init_t -> initrc_t -> daemon .. or did I miss / missunderstood something? From sds at tycho.nsa.gov Thu Feb 2 18:13:02 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 02 Feb 2006 13:13:02 -0500 Subject: extras package that require changes in selinux-policy (initng) In-Reply-To: <43E245F4.30309@feuerpokemon.de> References: <43DE4707.9010900@feuerpokemon.de> <43DE6A09.2040602@redhat.com> <43DF869C.1090700@feuerpokemon.de> <43E23C4C.4070203@feuerpokemon.de> <1138902557.18268.212.camel@moss-spartans.epoch.ncsc.mil> <43E245F4.30309@feuerpokemon.de> Message-ID: <1138903982.18268.216.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-02-02 at 18:48 +0100, dragoran wrote: > so what is the solution? use setexecon() to run the daemons as initrc_t > to let the domain transitions take effect? No, that wouldn't work, nor it is useful. > this should also be init_t -> initrc_t -> daemon .. or did I miss / > missunderstood something? As I said, the policy could be extended to include direct transitions from init_t -> daemon domains so that initng would work as is. But that needs to be taken up on selinux list and directed to refpolicy maintainers. -- Stephen Smalley National Security Agency From dragoran at feuerpokemon.de Thu Feb 2 18:26:13 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 02 Feb 2006 19:26:13 +0100 Subject: extras package that require changes in selinux-policy (initng) In-Reply-To: <1138903982.18268.216.camel@moss-spartans.epoch.ncsc.mil> References: <43DE4707.9010900@feuerpokemon.de> <43DE6A09.2040602@redhat.com> <43DF869C.1090700@feuerpokemon.de> <43E23C4C.4070203@feuerpokemon.de> <1138902557.18268.212.camel@moss-spartans.epoch.ncsc.mil> <43E245F4.30309@feuerpokemon.de> <1138903982.18268.216.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <43E24EC5.3000004@feuerpokemon.de> Stephen Smalley wrote: >On Thu, 2006-02-02 at 18:48 +0100, dragoran wrote: > > >>so what is the solution? use setexecon() to run the daemons as initrc_t >>to let the domain transitions take effect? >> >> > >No, that wouldn't work, nor it is useful. > > > >>this should also be init_t -> initrc_t -> daemon .. or did I miss / >>missunderstood something? >> >> > >As I said, the policy could be extended to include direct transitions >from init_t -> daemon domains so that initng would work as is. But that >needs to be taken up on selinux list and directed to refpolicy >maintainers. > > > filled bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179761 From selinux at gmail.com Thu Feb 2 20:35:01 2006 From: selinux at gmail.com (Tom London) Date: Thu, 2 Feb 2006 12:35:01 -0800 Subject: /var/run/NetworkManager.pid Message-ID: <4c4ba1530602021235x7aa116aasfe3a58eaa62ee19f@mail.gmail.com> Running latest rawhide, targeted/enforcing. [root at localhost run]# restorecon -v -R -n /var/run restorecon reset /var/run/NetworkManager.pid context system_u:object_r:initrc_var_run_t->system_u:object_r:NetworkManager_var_run_t [root at localhost run]# Does the following patch to /etc/rc.d/init.d/NetworkManager make sense? tom --- NetworkManager 2006-01-31 11:54:20.000000000 -0800 +++ NetworkManager.new 2006-02-02 12:33:19.000000000 -0800 @@ -41,6 +41,7 @@ RETVAL=$? echo [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$servicename && echo `/sbin/pidof $processname` > $pidfile + restorecon $pidfile } stop() -- Tom London From selinux at gmail.com Thu Feb 2 21:49:44 2006 From: selinux at gmail.com (Tom London) Date: Thu, 2 Feb 2006 13:49:44 -0800 Subject: NetWorkManagerDispatcher is initrc_t Message-ID: <4c4ba1530602021349w5a2e565cq6ee1180f00adfa25@mail.gmail.com> Running latest Rawhide, targeted/enforcing. NetworkManagerDispatcher appears to be running in initrc_t. Is that appropriate? Should it be NetworkManager_t like NetworkManager? Just checking. There aren't many things still running in initrc_t...... tom -- Tom London From Valdis.Kletnieks at vt.edu Fri Feb 3 18:19:52 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 03 Feb 2006 13:19:52 -0500 Subject: rawhide selinux-policy-strict whoopsage... In-Reply-To: Your message of "Thu, 02 Feb 2006 12:31:08 EST." <1138901468.18268.205.camel@moss-spartans.epoch.ncsc.mil> References: <200601261802.k0QI20ga016020@turing-police.cc.vt.edu> <1138822777.18268.82.camel@moss-spartans.epoch.ncsc.mil> <200602021718.k12HI819008489@turing-police.cc.vt.edu> <1138901468.18268.205.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200602031819.k13IJqr8008532@turing-police.cc.vt.edu> On Thu, 02 Feb 2006 12:31:08 EST, Stephen Smalley said: > On Thu, 2006-02-02 at 12:18 -0500, Valdis.Kletnieks at vt.edu wrote: > > 18 assertions. This looks fixable.... > > Yes, that is actually a bug in the copying of assertions during module > linking - no real assertions failed. Should be fixed in libsepol > 1.11.11. I snagged libsepol-1.11.12 and selinux-policy-strict-2.2.9-2 and now we have: ... Attempting to install module 'xserver.pp': Ok: return value of 0. Attempting to install module 'zebra.pp': Ok: return value of 0. Committing changes: libsepol.check_assertion_helper: assertion on line 0 violated by allow user_sudo_t user_sudo_t:process { setcurrent }; libsepol.check_assertion_helper: assertion on line 0 violated by allow staff_sudo_t staff_sudo_t:process { setcurrent }; libsepol.check_assertion_helper: assertion on line 0 violated by allow sysadm_sudo_t sysadm_sudo_t:process { setcurrent }; libsepol.check_assertions: 3 assertion violations occured libsemanage.semanage_expand_sandbox: Expand module failed semodule: Failed! Looks like 1 issue left in sudo.pp generating 3 asserts (the upgrade to libsepol 1.11.12 cleared 18 others). Haven't dug in yet whether this is another manifestation of the same/similar bug, or an actual sudo.pp issue. (in either case, "on line 0" is a busticated message...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Fri Feb 3 18:33:40 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 03 Feb 2006 13:33:40 -0500 Subject: rawhide selinux-policy-strict whoopsage... In-Reply-To: Your message of "Fri, 03 Feb 2006 13:19:52 EST." <200602031819.k13IJqr8008532@turing-police.cc.vt.edu> References: <200601261802.k0QI20ga016020@turing-police.cc.vt.edu> <1138822777.18268.82.camel@moss-spartans.epoch.ncsc.mil> <200602021718.k12HI819008489@turing-police.cc.vt.edu> <1138901468.18268.205.camel@moss-spartans.epoch.ncsc.mil> <200602031819.k13IJqr8008532@turing-police.cc.vt.edu> Message-ID: <200602031833.k13IXfKf009158@turing-police.cc.vt.edu> On Fri, 03 Feb 2006 13:19:52 EST, Valdis.Kletnieks at vt.edu said: > Committing changes: > libsepol.check_assertion_helper: assertion on line 0 violated by allow user_sudo_t user_sudo_t:process { setcurrent }; > libsepol.check_assertion_helper: assertion on line 0 violated by allow staff_sudo_t staff_sudo_t:process { setcurrent }; > libsepol.check_assertion_helper: assertion on line 0 violated by allow sysadm_sudo_t sysadm_sudo_t:process { setcurrent }; > libsepol.check_assertions: 3 assertion violations occured > libsemanage.semanage_expand_sandbox: Expand module failed > semodule: Failed! Follow-up - moving sudo.pp out of the way gets me this: Committing changes: /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /usr/sbin/sendmail.postfix. /etc/selinux/strict/contexts/files/file_contexts: Multiple different specifications for /var/spool/postfix(/.*)? (system_u:object_r:postfix_spool_t:s0 and system_u:object_r:mail_spool_t:s0). genhomedircon: Warning! No support yet for expanding ROLE macros in the /etc/selinux/strict/contexts/files/homedir_template file when using libsemanage. genhomedircon: You must manually update file_contexts.homedirs for any non-user_r users (including root). Ok: transaction number 101. Not perfect, but at least I'm back to running a functional 'strict' and only chasing quirks rather than total failures. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Fri Feb 3 18:46:57 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 03 Feb 2006 13:46:57 -0500 Subject: An interesting restorecon mislabel from selinux-policy-strict... Message-ID: <200602031846.k13Ikv0f009807@turing-police.cc.vt.edu> Now watching a 'restorecon -v -R /' run to fix everything that got borked while strict was broken... We have these file context entries: /usr/src(/.*)? system_u:object_r:src_t:s0 /usr(/.*)?/lib(64)?(/.*)? system_u:object_r:lib_t:s0 Guess what just happened to all the files under /usr/src/linux-2.6.16-foo/lib/ (Yes, moving the /usr/src/ entry lower in the file_contexts file should fix it, but I haven't got my head wrapped around the new package scheme enough to figure out how to accomplish that feat....) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From dwalsh at redhat.com Fri Feb 3 19:32:43 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 03 Feb 2006 14:32:43 -0500 Subject: rawhide selinux-policy-strict whoopsage... In-Reply-To: <200602031833.k13IXfKf009158@turing-police.cc.vt.edu> References: <200601261802.k0QI20ga016020@turing-police.cc.vt.edu> <1138822777.18268.82.camel@moss-spartans.epoch.ncsc.mil> <200602021718.k12HI819008489@turing-police.cc.vt.edu> <1138901468.18268.205.camel@moss-spartans.epoch.ncsc.mil> <200602031819.k13IJqr8008532@turing-police.cc.vt.edu> <200602031833.k13IXfKf009158@turing-police.cc.vt.edu> Message-ID: <43E3AFDB.9040703@redhat.com> Valdis.Kletnieks at vt.edu wrote: > On Fri, 03 Feb 2006 13:19:52 EST, Valdis.Kletnieks at vt.edu said: > > >> Committing changes: >> libsepol.check_assertion_helper: assertion on line 0 violated by allow user_sudo_t user_sudo_t:process { setcurrent }; >> libsepol.check_assertion_helper: assertion on line 0 violated by allow staff_sudo_t staff_sudo_t:process { setcurrent }; >> libsepol.check_assertion_helper: assertion on line 0 violated by allow sysadm_sudo_t sysadm_sudo_t:process { setcurrent }; >> libsepol.check_assertions: 3 assertion violations occured >> libsemanage.semanage_expand_sandbox: Expand module failed >> semodule: Failed! >> > > Follow-up - moving sudo.pp out of the way gets me this: > > Committing changes: > /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /usr/sbin/sendmail.postfix. > /etc/selinux/strict/contexts/files/file_contexts: Multiple different specifications for /var/spool/postfix(/.*)? (system_u:object_r:postfix_spool_t:s0 and system_u:object_r:mail_spool_t:s0). > genhomedircon: Warning! No support yet for expanding ROLE macros in the /etc/selinux/strict/contexts/files/homedir_template file when using libsemanage. > genhomedircon: You must manually update file_contexts.homedirs for any non-user_r users (including root). > Ok: transaction number 101. > > Not perfect, but at least I'm back to running a functional 'strict' and only chasing > quirks rather than total failures. ;) > > > Those are fixed in tonights rawhide. Currently available on ftp://people.redhat.com/dwalsh/SELinux/Fedora I am not seeing the sudo problems??? From dwalsh at redhat.com Fri Feb 3 19:52:27 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 03 Feb 2006 14:52:27 -0500 Subject: NetWorkManagerDispatcher is initrc_t In-Reply-To: <4c4ba1530602021349w5a2e565cq6ee1180f00adfa25@mail.gmail.com> References: <4c4ba1530602021349w5a2e565cq6ee1180f00adfa25@mail.gmail.com> Message-ID: <43E3B47B.4020606@redhat.com> Tom London wrote: > Running latest Rawhide, targeted/enforcing. > > NetworkManagerDispatcher appears to be running in initrc_t. Is that > appropriate? Should it be NetworkManager_t like NetworkManager? > > Just checking. There aren't many things still running in initrc_t...... > > tom > -- > Tom London > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > I have asked to have this patch applied to NetworkManager -------------- next part -------------- A non-text attachment was scrubbed... Name: NetworkManager.diff Type: text/x-diff Size: 551 bytes Desc: not available URL: From dwalsh at redhat.com Fri Feb 3 20:25:48 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 03 Feb 2006 15:25:48 -0500 Subject: NetWorkManagerDispatcher is initrc_t In-Reply-To: <43E3B47B.4020606@redhat.com> References: <4c4ba1530602021349w5a2e565cq6ee1180f00adfa25@mail.gmail.com> <43E3B47B.4020606@redhat.com> Message-ID: <43E3BC4C.8060500@redhat.com> Talking to the NetworkManager maintainer and came to the conclusion that these are quite different. So I think we would need policy specific to NetworkManagerDisapcher. Unfortunately that app is tough to lock down, since it has the ability to launch scripts when devices come up and down. It is envisioned that those scripts would interact with Kernel Modules and Iptables. So not really sure what do to with it. Dan From mayerf at tresys.com Fri Feb 3 20:30:29 2006 From: mayerf at tresys.com (Frank Mayer) Date: Fri, 3 Feb 2006 15:30:29 -0500 Subject: SELinux Symposium: Second Keynote Speaker announced Message-ID: <012001c62900$ad379e40$8c0d010a@columbia.tresys.com> For those planning to go the SELinux Symposium, a second keynote speaker has just been announced. The press release is below. The agenda for the technical session has also been updated; see the symposium's web site (www.selinux-symposium.org). Frank -=-=-=-=-=-=- Second Keynote Speaker Announced for the Second Security-Enhanced Linux Symposium and Developer Summit Event slated for February 27-March 3, 2006 in Baltimore, Maryland, USA Baltimore, MD - (February, 02 2006) - Dr. Steve Marsh, Director of the Central Sponsor for Information Assurance unit in the UK Cabinet Office, will be a keynote speaker for the second annual Security-Enhanced Linux (SELinux) Symposium scheduled for February 27-March 3, 2006 in Baltimore, Maryland. The Central Sponsor for Information Assurance unit was formed in October 2002 to provide assurance to government that the risks to the UK national information infrastructure are appropriately managed. Prior to this assignment, Dr. Marsh was Director of Security Policy in the Office of the e-Envoy, responsible for establishing a common framework for the security of electronic government systems. This included the ways by which individuals and business users authenticate themselves when using electronic government services. He has over 15 years experience in security and IT within the public sector. Dr. Marsh will present a keynote address entitled "UK e-Government: Security Challenges and Solutions for Innovative Service Delivery." In this address, Dr. Marsh will share some of the security challenges facing e-Government services in the UK, as well as some of the solutions being explored to address these challenges. SELinux is being explored as one of a number of aids to securing UK e-government services. SELinux has the ability to provide enhanced information assurance for key infrastructure components and applications. A separate case study to be presented during the symposium will discuss the planned use of SELinux in an UK e-Government pilot program. 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 tibbs at math.uh.edu Fri Feb 3 21:36:56 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 03 Feb 2006 15:36:56 -0600 Subject: Bonehead basic selinux questions Message-ID: OK, I've done a lot of reading and I've even done some policy hacking. But there are some fundamental things about selinux I just don't understand yet. So I do a fresh FC4 install, log in, mkdir /local and make and mount a couple of filesystems under it: /svn and /trac. I do chcon -R --reference=/var/www /local/svn and httpd can see stuff under /local/svn without issue. So I wonder if that change is permanent or if I'll get boned if the system gets relabeled: > s restorecon -n -R -v /local /sbin/restorecon reset /local context root:object_r:root_t->system_u:object_r:default_t /sbin/restorecon reset /local/trac context system_u:object_r:file_t->system_u:object_r:default_t /sbin/restorecon reset /local/trac/lost+found context system_u:object_r:file_t->system_u:object_r:default_t Looks OK; the context on /local/svn isn't going to change. So I go ahead and drop the '-n' so I'm not surprised later, which had the effect of surprising me immediately. Now httpd can't look in /local/svn (because it can't see under /local?): > s ausearch -i -ui apache [...blah...] type=PATH msg=audit(02/03/06 15:22:17.034:320) : item=0 name=/local flags=none inode=65545 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(02/03/06 15:22:17.034:320) : cwd=/ type=AVC_PATH msg=audit(02/03/06 15:22:17.034:320) : path=/local type=SYSCALL msg=audit(02/03/06 15:22:17.034:320) : arch=i386 syscall=lstat64 success=no exit=-13(Permission denied) a0=8db7f40 a1=bfbeb7bc a2=dc6ff4 a3=bfbeb7bc items=1 pid=8587 auid=tibbs uid=apache gid=apache euid=apache suid=apache fsuid=apache egid=apache sgid=apache fsgid=apache comm=httpd exe=/usr/sbin/httpd type=AVC msg=audit(02/03/06 15:22:17.034:320) : avc: denied { getattr } for pid=8587 comm=httpd name=local dev=dm-0 ino=65545 scontext=root:system_r:httpd_t tcontext=system_u:object_r:default_t tclass=dir So changing the context from root:object_r:root_t to system_u:object_r:default_t locks httpd out? I have not changed the policy booleans from their default values: allow_httpd_anon_write inactive allow_httpd_sys_script_anon_write inactive httpd_builtin_scripting active httpd_can_network_connect inactive httpd_disable_trans inactive httpd_enable_cgi active httpd_enable_ftp_server inactive httpd_enable_homedirs active httpd_ssi_exec active httpd_suexec_disable_trans inactive httpd_tty_comm inactive httpd_unified active I don't think it would be proper to chcon /local to the same context as /local/svn, because I will certainly mount non-httpd-visible things under /local. So what is the proper way to fix this? Any enlightenment would be very much appreciated, - J< From zico at algohotellet.se Sat Feb 4 14:21:33 2006 From: zico at algohotellet.se (pi) Date: Sat, 4 Feb 2006 15:21:33 +0100 Subject: (no subject) Message-ID: I have a site made in joomla, placed under a users public_html. Everything works exept for one optional thing within the php/mysql-section. Now when i look at the output of: ls -adZ /home/xyz-user/public_html i get this: drwxr-xr-x xyz-user xyz-user root:object_r:user_home_t /home/xyz-user/public_htmldrwxr-xr-x root root root:object_r:user_home_t /home/xyz-user/public_html Is there any command i can give in terminal so set it right, and do i need to relabel the system after that? Regards /pi From zico at algohotellet.se Sat Feb 4 14:24:56 2006 From: zico at algohotellet.se (pi) Date: Sat, 4 Feb 2006 15:24:56 +0100 Subject: =?iso-8859-1?q?selinux_syntax_f=F6r_owner?= Message-ID: Sorry all, i should have set a subject ti this to. I appologise for the first one. I have a site made in joomla, placed under a users public_html. Everything works exept for one optional thing within the php/mysql-section. Now when i look at the output of: ls -adZ /home/xyz-user/public_html i get this: drwxr-xr-x xyz-user xyz-user root:object_r:user_home_t /home/xyz-user/public_htmldrwxr-xr-x root root root:object_r:user_home_t /home/xyz-user/public_html Is there any command i can give in terminal so set it right, and do i need to relabel the system after that? Regards /pi From zico at algohotellet.se Sat Feb 4 14:31:16 2006 From: zico at algohotellet.se (pi) Date: Sat, 4 Feb 2006 15:31:16 +0100 Subject: =?iso-8859-1?q?selinux_syntax_f=F6r_owner=2C_disregard_the_previ?= =?iso-8859-1?q?ous_ones?= Message-ID: <274236fd6d175555281b6c379e9380e4@algohotellet.se> Damn, i?m ashame. everything seems to go wrong today. I have a site made in joomla, placed under a users public_html. Everything works exept for one optional thing within the php/mysql-section. Now when i look at the output of: ls -adZ /home/xyz-user/public_html i get this: drwxr-xr-x xyz-user xyz-user root:object_r:user_home_t /home/xyz-user/public_html It probaably should look like this: drwxr-xr-x root root root:object_r:user_home_t /home/xyz-user/public_html Is there any command i can give in terminal so set it right, and do i need to relabel the system after that? Regards /pi From mjs at ces.clemson.edu Sun Feb 5 04:35:09 2006 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Sat, 4 Feb 2006 23:35:09 -0500 (EST) Subject: AVCs denied from latest FC4 kernel startup Message-ID: After installing kernel-2.6.15-1.1830_FC4 (or any of the 2.6.15 kernels), I get the following on startup. Startup appears to complete normally and the system seems functional (at least for what I've tried so far). audit(1139113698.796:2): avc: denied { search } for pid=578 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.804:3): avc: denied { search } for pid=579 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.808:4): avc: denied { search } for pid=572 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.816:5): avc: denied { search } for pid=580 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.824:6): avc: denied { search } for pid=567 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.832:7): avc: denied { search } for pid=581 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.844:8): avc: denied { search } for pid=568 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.852:9): avc: denied { search } for pid=582 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.860:10): avc: denied { search } for pid=569 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.872:11): avc: denied { search } for pid=583 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.880:12): avc: denied { search } for pid=571 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.892:13): avc: denied { search } for pid=584 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.900:14): avc: denied { search } for pid=574 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.912:15): avc: denied { search } for pid=575 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.924:16): avc: denied { search } for pid=576 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.936:17): avc: denied { search } for pid=587 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.948:18): avc: denied { search } for pid=577 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.960:19): avc: denied { search } for pid=586 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.976:20): avc: denied { search } for pid=570 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir audit(1139113698.988:21): avc: denied { search } for pid=573 comm="hotplug" name="proc" dev=dm-0 ino=851969 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:unlabeled_t tclass=dir -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From dpaul at gmx.net Sun Feb 5 17:15:16 2006 From: dpaul at gmx.net (Daniel Paul) Date: Sun, 5 Feb 2006 18:15:16 +0100 Subject: Problem with interbase (firebird-1.5) on FC4 box, httpd-2.0.54, php-interbase-5.0.4-10.5 In-Reply-To: <43DFD5C7.4080901@redhat.com> References: <200601301639.21188.dpaul@gmx.net> <43DFD5C7.4080901@redhat.com> Message-ID: <200602051815.16697.dpaul@gmx.net> Hello again, execstack -c /usr/lib/modules/interbase.so does not solve the problem, execstack -s and -c show the same behaviour (same error message, see below). Maybe some more information: ls -Z for interbase shows: -rwxr-xr-x root root system_u:object_r:lib_t interbase.so BTW: /usr/lib/httpd/libphp5.so has the same context data: -rwxr-xr-x root root system_u:object_r:lib_t libphp5.so (shouldn't it be -> t=httpd_modules_t ?) Tell me if you need more input to solve the problem... Daniel > 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 nicolas.mailhot at laposte.net Sun Feb 5 19:57:17 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 05 Feb 2006 20:57:17 +0100 Subject: some selinux logs Message-ID: <1139169438.5786.22.camel@rousalka.dyndns.org> Hi, After a long pause (had a kernel FS corruption to track) here is a new selinux-on-x86_64-rawhide report. Attached are full audit logs since yesterday (after a system relabel) libselinux-1.29.6-1 libselinux-devel-1.29.6-1 selinux-policy-2.2.11-1 libselinux-python-1.29.6-1 selinux-policy-targeted-2.2.11-1 libselinux-1.29.6-1 The logs speak for themselves I had to disable enforcing today to rescue evo, firefox and other nss users. They did work just after the labelling Seems system background processes mess the labeling, so initial boot after relabel is ok but after a while all hell breaks loose. I suspect prelink (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177976) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: audit.log.bz2 Type: application/x-bzip Size: 36609 bytes Desc: not available URL: -------------- 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 selinux at gmail.com Sun Feb 5 20:32:27 2006 From: selinux at gmail.com (Tom London) Date: Sun, 5 Feb 2006 12:32:27 -0800 Subject: crond execheap Message-ID: <4c4ba1530602051232k55348d26r861fd895593e6564@mail.gmail.com> Running latest rawhide, targeted/enforcing. I notice this in audit.log: ---- type=SYSCALL msg=audit(02/05/2006 10:32:52.810:590) : arch=i386 syscall=mprotect success=no exit=-13(Permission denied) a0=4b25000 a1=6f000 a2=5 a3=bfd4d600 items=0 pid=7034 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=ld-linux.so.2 exe=/lib/ld-2.3.90.so type=AVC msg=audit(02/05/2006 10:32:52.810:590) : avc: denied { execheap } for pid=7034 comm=ld-linux.so.2 scontext=system_u:system_r:crond_t:s0 tcontext=system_u:system_r:crond_t:s0 tclass=process ---- Not sure how to track this down further.... tom -- Tom London From bobk at ocf.berkeley.edu Sun Feb 5 21:22:18 2006 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Sun, 05 Feb 2006 13:22:18 -0800 Subject: AVCs denied from latest FC4 kernel startup In-Reply-To: References: Message-ID: <1139174538.2401.5.camel@chaucer> On Sat, 2006-02-04 at 23:35 -0500, Matthew Saltzman wrote: > After installing kernel-2.6.15-1.1830_FC4 (or any of the 2.6.15 kernels), > I get the following on startup. Startup appears to complete normally and > the system seems functional (at least for what I've tried so far). > > audit(1139113698.796:2): avc: denied { search } for pid=578 > comm="hotplug" name="proc" dev=dm-0 ino=851969 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:unlabeled_t tclass=dir Matt, what's the context of /etc/hotplug and /sbin/hotplug? I have this: drwxr-xr-x root root system_u:object_r:hotplug_etc_t /etc/hotplug drwxr-xr-x root root system_u:object_r:etc_t /etc/hotplug.d -rwxr-xr-x root root system_u:object_r:hotplug_exec_t /sbin/hotplug Try /sbin/restorecon -R /etc/hotplug* /sbin/hotplug Bob -- Bob Kashani GARNOME Project http://www.gnome.org/projects/garnome http://www.ocf.berkeley.edu/~bobk/garnome From russell at coker.com.au Sun Feb 5 23:55:38 2006 From: russell at coker.com.au (Russell Coker) Date: Mon, 6 Feb 2006 10:55:38 +1100 Subject: (no subject) In-Reply-To: References: Message-ID: <200602061055.46921.russell@coker.com.au> On Sunday 05 February 2006 01:21, pi wrote: > I have a site made in joomla, placed under a users public_html. > Everything works exept for one optional thing within the > php/mysql-section. > > Now when i look at the output of: > ls -adZ /home/xyz-user/public_html > i get this: > drwxr-xr-x xyz-user xyz-user root:object_r:user_home_t > /home/xyz-user/public_htmldrwxr-xr-x root root > root:object_r:user_home_t /home/xyz-user/public_html > > Is there any command i can give in terminal so set it right, As administrator "restorecon -R -v /home/xya-user/public_html", as user "chcon -R -t httpd_sys_content_t ~/public_html". > and do i need to relabel the system after that? The above commands can be used instead of relabeling the system. Relabeling the system would achieve the same result but take much longer. Best to just use restorecon to relabel the parts that need 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 sds at tycho.nsa.gov Mon Feb 6 13:32:24 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 06 Feb 2006 08:32:24 -0500 Subject: Bonehead basic selinux questions In-Reply-To: References: Message-ID: <1139232744.31135.10.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-02-03 at 15:36 -0600, Jason L Tibbitts III wrote: > OK, I've done a lot of reading and I've even done some policy > hacking. But there are some fundamental things about selinux I just > don't understand yet. > > So I do a fresh FC4 install, log in, mkdir /local and make and mount a > couple of filesystems under it: /svn and /trac. > > I do chcon -R --reference=/var/www /local/svn > > and httpd can see stuff under /local/svn without issue. > > So I wonder if that change is permanent or if I'll get boned if the > system gets relabeled: > > > s restorecon -n -R -v /local > /sbin/restorecon reset /local context root:object_r:root_t->system_u:object_r:default_t > /sbin/restorecon reset /local/trac context system_u:object_r:file_t->system_u:object_r:default_t > /sbin/restorecon reset /local/trac/lost+found context system_u:object_r:file_t->system_u:object_r:default_t You can make the change permanent by creating a /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts.local file that specifies the paths and desired contexts for your local customizations. Certain types are also automatically excluded from relabeling by default via /etc/selinux/$SELINUXTYPE/contexts/customizable_types. > Looks OK; the context on /local/svn isn't going to change. So I go > ahead and drop the '-n' so I'm not surprised later, which had the > effect of surprising me immediately. Now httpd can't look in > /local/svn (because it can't see under /local?): > > > s ausearch -i -ui apache > [...blah...] > type=PATH msg=audit(02/03/06 15:22:17.034:320) : item=0 name=/local flags=none inode=65545 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 > type=CWD msg=audit(02/03/06 15:22:17.034:320) : cwd=/ > type=AVC_PATH msg=audit(02/03/06 15:22:17.034:320) : path=/local > type=SYSCALL msg=audit(02/03/06 15:22:17.034:320) : arch=i386 syscall=lstat64 success=no exit=-13(Permission denied) a0=8db7f40 a1=bfbeb7bc a2=dc6ff4 a3=bfbeb7bc items=1 pid=8587 auid=tibbs uid=apache gid=apache euid=apache suid=apache fsuid=apache egid=apache sgid=apache fsgid=apache comm=httpd exe=/usr/sbin/httpd > type=AVC msg=audit(02/03/06 15:22:17.034:320) : avc: denied { getattr } for pid=8587 comm=httpd name=local dev=dm-0 ino=65545 scontext=root:system_r:httpd_t tcontext=system_u:object_r:default_t tclass=dir > > So changing the context from root:object_r:root_t to > system_u:object_r:default_t locks httpd out? Yes. As default_t is the type applied to anything not otherwise specified (matching the /.* regex at the top of file_contexts), we don't want it to be accessible at all to the confined daemons. Whereas most daemons need to be able to search the root directory (and hence have some basic permissions to root_t). > I don't think it would be proper to chcon /local to the same context > as /local/svn, because I will certainly mount non-httpd-visible things > under /local. So what is the proper way to fix this? > > Any enlightenment would be very much appreciated, Put a type on it that is accessible, and preserve it using file_contexts.local. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Feb 6 13:57:33 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 06 Feb 2006 08:57:33 -0500 Subject: AVCs denied from latest FC4 kernel startup In-Reply-To: References: Message-ID: <1139234253.31135.38.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2006-02-04 at 23:35 -0500, Matthew Saltzman wrote: > After installing kernel-2.6.15-1.1830_FC4 (or any of the 2.6.15 kernels), > I get the following on startup. Startup appears to complete normally and > the system seems functional (at least for what I've tried so far). > > audit(1139113698.796:2): avc: denied { search } for pid=578 > comm="hotplug" name="proc" dev=dm-0 ino=851969 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:unlabeled_t tclass=dir Likely an interleaving of device detection / hotplug execution with the initial policy load by init, during which inodes are still being set up by SELinux. bugzilla against the kernel please. -- Stephen Smalley National Security Agency From notting at redhat.com Mon Feb 6 15:46:05 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Feb 2006 10:46:05 -0500 Subject: [kay.sievers@vrfy.org] Message-ID: <20060206154605.GB32552@devserv.devel.redhat.com> Some questions from the upstream udev maintainer... from reading it, the media stuff is because CDROMs, etc. have a different file type, and the defaultfile context needs set in everything that creates devices. Is that correct? Bill ----- Forwarded message from Kay Sievers ----- Date: Sat, 4 Feb 2006 05:10:04 +0100 From: Kay Sievers To: Bill Nottingham ... Can't we move the selinux_init() called from every event process to the single main daemon init? I don't know how expensive that is, nor do I know if selinux is fine with that, but if we can make that faster it would be better... And the get_media() in udev_selinux.c for every block device seems a bit weird. Do you know if this really needed? What about scsi then? I've added the IDE stuff to sysfs in 2.6.15, so we should at least use the file there... Care to ask one of your selinux guys or forward the questions? Cheers, Kay ----- End forwarded message ----- From sds at tycho.nsa.gov Mon Feb 6 16:14:08 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 06 Feb 2006 11:14:08 -0500 Subject: [kay.sievers@vrfy.org] In-Reply-To: <20060206154605.GB32552@devserv.devel.redhat.com> References: <20060206154605.GB32552@devserv.devel.redhat.com> Message-ID: <1139242448.31135.73.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2006-02-06 at 10:46 -0500, Bill Nottingham wrote: > Some questions from the upstream udev maintainer... from reading > it, the media stuff is because CDROMs, etc. have a different file > type, and the defaultfile context needs set in everything that > creates devices. Is that correct? Dan Walsh wrote the original udev SELinux support, so take this with a grain of salt, but I think that you are correct. The usual file contexts approach of labeling based on pathname regex wasn't sufficient for removable media, so Dan introduced the specialized media handling. On Kay's selinux_init question: > Can't we move the selinux_init() called from every event process > to the single main daemon init? I don't know how expensive that is, > nor do I know if selinux is fine with that, but if we can make that > faster it would be better... The expensive part of selinux_init is matchpathcon_init, but that should be somewhat alleviated by the introduction of matchpathcon_init_prefix so that only the necessary file_contexts entries are processed and the libselinux changes to perform lazy canonicalization of the security contexts. The matchpathcon_init has to be done in the process that performs the subsequent matchpathcon calls, as it populates an in-memory data structure used by matchpathcon. Conceivably, both the matchpathcon_init_prefix and the later matchpathcon calls could be done in the parent daemon and the children could receive the appropriate context info from the parent via a pipe or commandline argument, but someone would have to work out the details there. The rest of selinux_init is just saving the old file creation context (if one was previously set) so that it can be restored later. In practice, I suspect that this is always NULL for udev, and we could "optimize" this away, but it is safer to always save-and-restore it, and that isn't the expensive part. > And the get_media() in udev_selinux.c for every block device seems > a bit weird. Do you know if this really needed? What about scsi then? > I've added the IDE stuff to sysfs in 2.6.15, so we should at least > use the file there... Not sure - I'll defer to Dan on this. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon Feb 6 16:40:59 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 06 Feb 2006 11:40:59 -0500 Subject: selinux syntax =?iso-8859-1?q?f=F6r_owner?= In-Reply-To: References: Message-ID: <43E77C1B.2040206@redhat.com> pi wrote: > > Sorry all, i should have set a subject ti this to. I appologise for > the first one. > > I have a site made in joomla, placed under a users public_html. > Everything works exept for one optional thing within the > php/mysql-section. > > Now when i look at the output of: > ls -adZ /home/xyz-user/public_html What happens when you restorecon -R -v /home/xyz-user/public_html? > i get this: > drwxr-xr-x xyz-user xyz-user root:object_r:user_home_t > /home/xyz-user/public_htmldrwxr-xr-x root root > root:object_r:user_home_t /home/xyz-user/public_html > > Is there any command i can give in terminal so set it right, and do i > need to relabel the system after that? > > > Regards > /pi > > -- > 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 Feb 6 16:59:28 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 06 Feb 2006 11:59:28 -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: <200602051815.16697.dpaul@gmx.net> References: <200601301639.21188.dpaul@gmx.net> <43DFD5C7.4080901@redhat.com> <200602051815.16697.dpaul@gmx.net> Message-ID: <43E78070.3040304@redhat.com> Daniel Paul wrote: > Hello again, > > execstack -c /usr/lib/modules/interbase.so does not solve the problem, > execstack -s and -c show the same behaviour (same error message, see below). > > Maybe some more information: > ls -Z for interbase shows: > -rwxr-xr-x root root system_u:object_r:lib_t interbase.so > > BTW: /usr/lib/httpd/libphp5.so has the same context data: > -rwxr-xr-x root root system_u:object_r:lib_t libphp5.so > > (shouldn't it be -> t=httpd_modules_t ?) > > Tell me if you need more input to solve the problem... > > Daniel > > > > > >> 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. >>> >>> After you execute execstack -c /usr/lib/modules/interbase.so Are you still seeing avc messages? Dan >>> Thanks in advance, >>> >>> Daniel >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From dpaul at gmx.net Mon Feb 6 17:38:23 2006 From: dpaul at gmx.net (Daniel Paul) Date: Mon, 6 Feb 2006 18:38:23 +0100 Subject: Problem with interbase (firebird-1.5) on FC4 box, httpd-2.0.54, php-interbase-5.0.4-10.5 In-Reply-To: <43E78070.3040304@redhat.com> References: <200601301639.21188.dpaul@gmx.net> <200602051815.16697.dpaul@gmx.net> <43E78070.3040304@redhat.com> Message-ID: <200602061838.23793.dpaul@gmx.net> Hello Dan, yes, I do see the same error messages as before: type=AVC msg=audit(1139247428.906:1665): avc: denied { execstack } for pid=32571 comm="httpd" scontext=root:system_r:httpd_t tcontext=ro ot:system_r:httpd_t tclass=process type=SYSCALL msg=audit(1139247428.906:1665): arch=40000003 syscall=125 success=no exit=-13 a0=bff51000 a1=1000 a2=1000007 a3=3c9000 items=0 pid=32571 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd" exe="/usr/sbin/httpd" Do I need to reboot the server after executing execstack -c ? Greetings, Daniel > Daniel Paul wrote: > > Hello again, > > > > execstack -c /usr/lib/modules/interbase.so does not solve the problem, > > execstack -s and -c show the same behaviour (same error message, see > > below). > > > > Maybe some more information: > > ls -Z for interbase shows: > > -rwxr-xr-x root root system_u:object_r:lib_t interbase.so > > > > BTW: /usr/lib/httpd/libphp5.so has the same context data: > > -rwxr-xr-x root root system_u:object_r:lib_t libphp5.so > > > > (shouldn't it be -> t=httpd_modules_t ?) > > > > Tell me if you need more input to solve the problem... > > > > Daniel > > > >> 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. > > After you execute > > execstack -c /usr/lib/modules/interbase.so > > Are you still seeing avc messages? > > Dan > > >>> Thanks in advance, > >>> > >>> Daniel > >>> > >>> -- > >>> fedora-selinux-list mailing list > >>> fedora-selinux-list at redhat.com > >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > -- > > 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 Feb 6 18:15:29 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 06 Feb 2006 13:15:29 -0500 Subject: [kay.sievers@vrfy.org] In-Reply-To: <1139242448.31135.73.camel@moss-spartans.epoch.ncsc.mil> References: <20060206154605.GB32552@devserv.devel.redhat.com> <1139242448.31135.73.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <43E79241.8010805@redhat.com> Stephen Smalley wrote: > On Mon, 2006-02-06 at 10:46 -0500, Bill Nottingham wrote: > >> Some questions from the upstream udev maintainer... from reading >> it, the media stuff is because CDROMs, etc. have a different file >> type, and the defaultfile context needs set in everything that >> creates devices. Is that correct? >> > > Dan Walsh wrote the original udev SELinux support, so take this with a > grain of salt, but I think that you are correct. The usual file > contexts approach of labeling based on pathname regex wasn't sufficient > for removable media, so Dan introduced the specialized media handling. > > On Kay's selinux_init question: > > >> Can't we move the selinux_init() called from every event process >> to the single main daemon init? I don't know how expensive that is, >> nor do I know if selinux is fine with that, but if we can make that >> faster it would be better... >> > > The expensive part of selinux_init is matchpathcon_init, but that should > be somewhat alleviated by the introduction of matchpathcon_init_prefix > so that only the necessary file_contexts entries are processed and the > libselinux changes to perform lazy canonicalization of the security > contexts. > > The matchpathcon_init has to be done in the process that performs the > subsequent matchpathcon calls, as it populates an in-memory data > structure used by matchpathcon. Conceivably, both the > matchpathcon_init_prefix and the later matchpathcon calls could be done > in the parent daemon and the children could receive the appropriate > context info from the parent via a pipe or commandline argument, but > someone would have to work out the details there. > > The rest of selinux_init is just saving the old file creation context > (if one was previously set) so that it can be restored later. In > practice, I suspect that this is always NULL for udev, and we could > "optimize" this away, but it is safer to always save-and-restore it, and > that isn't the expensive part. > > >> And the get_media() in udev_selinux.c for every block device seems >> a bit weird. Do you know if this really needed? What about scsi then? >> I've added the IDE stuff to sysfs in 2.6.15, so we should at least >> use the file there... >> > > Not sure - I'll defer to Dan on this. > > How about if we changed the call to if ( mode & S_IFBLK ) { media = get_media(devname, mode); if (media) { ret = matchmediacon(media, &scontext); free(media); } } From sds at tycho.nsa.gov Mon Feb 6 18:35:35 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 06 Feb 2006 13:35:35 -0500 Subject: [kay.sievers@vrfy.org] In-Reply-To: <43E79241.8010805@redhat.com> References: <20060206154605.GB32552@devserv.devel.redhat.com> <1139242448.31135.73.camel@moss-spartans.epoch.ncsc.mil> <43E79241.8010805@redhat.com> Message-ID: <1139250935.31135.129.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2006-02-06 at 13:15 -0500, Daniel J Walsh wrote: > How about if we changed the call to > if ( mode & S_IFBLK ) { > media = get_media(devname, mode); > if (media) { > ret = matchmediacon(media, &scontext); > free(media); > } > } You already have a test of (mode & S_IFBLK) on entry to get_media, so I don't see what that buys you. Still limited to ide devices by get_media only checking /proc/ide. I don't think her concern with the media support was performance, just generality and use of sysfs. Performance concern was with selinux_init. On the performance overhead issue, only real improvement would be to move all matchpathcon_init+matchpathcon processing into the daemon and have the daemon pass the required contexts to the event commands on the command line or via pipe. -- Stephen Smalley National Security Agency From oil.pine at gmail.com Mon Feb 6 18:32:31 2006 From: oil.pine at gmail.com (pine oil) Date: Mon, 6 Feb 2006 12:32:31 -0600 Subject: selinux causes a problem with cdrom mounting on Fedora Core 3 Message-ID: I've just installed FC3 onto my machine because FC4 refused to install complaining it could could not configure my graphic card (Matrox Millennium P750). CD does not get mounted properly apparently due to SELinux as indicated in the /etc/fstab as below. I edited the file to eliminated the entry made by SELinux. On reboot, the same entry appears again. What do I do now? Your suggesion will be appreciated very much. pine ======================== /etc/fstab ====================== # This file is edited by fstab-sync - see 'man fstab-sync' for details LABEL=/ / ext3 defaults 1 1 LABEL=/boot1 /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 LABEL=SWAP-hda3 swap swap defaults 0 0 /dev/hdc /media/cdrom auto pamconsole,fscontext=system_u:object_r:removable_t,ro,exec,noauto,managed 0 0 ============================================================ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjs at ces.clemson.edu Mon Feb 6 19:40:47 2006 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Mon, 6 Feb 2006 14:40:47 -0500 (EST) Subject: AVCs denied from latest FC4 kernel startup In-Reply-To: <1139234253.31135.38.camel@moss-spartans.epoch.ncsc.mil> References: <1139234253.31135.38.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Mon, 6 Feb 2006, Stephen Smalley wrote: > On Sat, 2006-02-04 at 23:35 -0500, Matthew Saltzman wrote: >> After installing kernel-2.6.15-1.1830_FC4 (or any of the 2.6.15 kernels), >> I get the following on startup. Startup appears to complete normally and >> the system seems functional (at least for what I've tried so far). >> >> audit(1139113698.796:2): avc: denied { search } for pid=578 >> comm="hotplug" name="proc" dev=dm-0 ino=851969 >> scontext=system_u:system_r:hotplug_t >> tcontext=system_u:object_r:unlabeled_t tclass=dir > > Likely an interleaving of device detection / hotplug execution with the > initial policy load by init, during which inodes are still being set up > by SELinux. bugzilla against the kernel please. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180179 -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From mjs at ces.clemson.edu Mon Feb 6 20:00:41 2006 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Mon, 6 Feb 2006 15:00:41 -0500 (EST) Subject: AVCs denied from latest FC4 kernel startup In-Reply-To: <1139174538.2401.5.camel@chaucer> References: <1139174538.2401.5.camel@chaucer> Message-ID: On Sun, 5 Feb 2006, Bob Kashani wrote: > On Sat, 2006-02-04 at 23:35 -0500, Matthew Saltzman wrote: >> After installing kernel-2.6.15-1.1830_FC4 (or any of the 2.6.15 kernels), >> I get the following on startup. Startup appears to complete normally and >> the system seems functional (at least for what I've tried so far). >> >> audit(1139113698.796:2): avc: denied { search } for pid=578 >> comm="hotplug" name="proc" dev=dm-0 ino=851969 >> scontext=system_u:system_r:hotplug_t >> tcontext=system_u:object_r:unlabeled_t tclass=dir > > Matt, what's the context of /etc/hotplug and /sbin/hotplug? I have this: > > drwxr-xr-x root root > system_u:object_r:hotplug_etc_t /etc/hotplug > drwxr-xr-x root root > system_u:object_r:etc_t /etc/hotplug.d > -rwxr-xr-x root root > system_u:object_r:hotplug_exec_t /sbin/hotplug > > Try /sbin/restorecon -R /etc/hotplug* /sbin/hotplug $ ls -dZ /etc/hotplug.* /sbin/hotplug drwxr-xr-x root root system_u:object_r:etc_t /etc/hotplug.d drwxr-xr-x root root system_u:object_r:hotplug_etc_t /etc/hotplug -rwxr-xr-x root root system_u:object_r:hotplug_exec_t /sbin/hotplug After the restorecon, mine are the same as yours. The startup messages are nto affected. BTW, I get the same startup messages in 2.6.14 FC4 kernels if I boot in non-quiet mode. I filed a bug against the kernel as requested by Stephen Smalley. > > Bob > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From dwalsh at redhat.com Mon Feb 6 20:36:56 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 06 Feb 2006 15:36:56 -0500 Subject: crond execheap In-Reply-To: <4c4ba1530602051232k55348d26r861fd895593e6564@mail.gmail.com> References: <4c4ba1530602051232k55348d26r861fd895593e6564@mail.gmail.com> Message-ID: <43E7B368.80704@redhat.com> Tom London wrote: > Running latest rawhide, targeted/enforcing. > > I notice this in audit.log: > ---- > type=SYSCALL msg=audit(02/05/2006 10:32:52.810:590) : arch=i386 > syscall=mprotect success=no exit=-13(Permission denied) a0=4b25000 > a1=6f000 a2=5 a3=bfd4d600 items=0 pid=7034 auid=unknown(4294967295) > uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root > fsgid=root comm=ld-linux.so.2 exe=/lib/ld-2.3.90.so > type=AVC msg=audit(02/05/2006 10:32:52.810:590) : avc: denied { > execheap } for pid=7034 comm=ld-linux.so.2 > scontext=system_u:system_r:crond_t:s0 > tcontext=system_u:system_r:crond_t:s0 tclass=process > ---- > > This should not happen. Do you know what crond is generating this? Nothing should be running ld-linus.so.2 Dan > Not sure how to track this down further.... > > tom > -- > Tom London > > -- > 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 Feb 6 20:49:22 2006 From: selinux at gmail.com (Tom London) Date: Mon, 6 Feb 2006 12:49:22 -0800 Subject: crond execheap In-Reply-To: <43E7B368.80704@redhat.com> References: <4c4ba1530602051232k55348d26r861fd895593e6564@mail.gmail.com> <43E7B368.80704@redhat.com> Message-ID: <4c4ba1530602061249y8a37c60o645dc2c308ff31a3@mail.gmail.com> I see this in /var/log/cron*: Feb 5 09:12:04 localhost crond[2534]: (CRON) STARTUP (V5.0) Feb 5 09:12:07 localhost anacron[2564]: Anacron 2.3 started on 2006-02-05 Feb 5 09:12:07 localhost anacron[2564]: Will run job `cron.daily' in 65 min. Feb 5 09:12:07 localhost anacron[2564]: Jobs will be executed sequentially Feb 5 10:01:01 localhost crond[3752]: (root) CMD (run-parts /etc/cron.hourly) Feb 5 10:17:07 localhost anacron[2564]: Job `cron.daily' started Feb 5 10:17:08 localhost anacron[3827]: Updated timestamp for job `cron.daily' Feb 5 10:37:19 localhost anacron[2564]: Job `cron.daily' terminated Feb 5 10:37:19 localhost anacron[2564]: Normal exit (1 jobs run) cron.daily? From mayerf at tresys.com Mon Feb 6 22:05:50 2006 From: mayerf at tresys.com (Frank Mayer) Date: Mon, 6 Feb 2006 17:05:50 -0500 Subject: SELinux Symposium Final Agenda: Case studies, WIPS, and BOFs Message-ID: <021201c62b69$7dc48770$8c0d010a@columbia.tresys.com> The final agenda for the SELinux Symposium has been posted to the symposium web site (www.selinux-symposium.org). In particular we have now included two case studies, seven work-in-progress presentations, and two birds-of-a-feather session to the agenda. For those planning to attend, early (discounted) registration ends this Friday (February 10), so don't delay registering. See you there, Frank From drepper at redhat.com Tue Feb 7 04:10:59 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Mon, 06 Feb 2006 20:10:59 -0800 Subject: crond execheap In-Reply-To: <43E7B368.80704@redhat.com> References: <4c4ba1530602051232k55348d26r861fd895593e6564@mail.gmail.com> <43E7B368.80704@redhat.com> Message-ID: <43E81DD3.2050501@redhat.com> Daniel J Walsh wrote: > Nothing should be running ld-linus.so.2 Actually, Dan, I think I know what it is: prelink. The scripts run ldd on init. So, what does /sbin/init look like on the system where the messages are printed? Is it the latest init from rawhide? Please show the output of readelf -dl /sbin/init -- ? 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 bobk at ocf.berkeley.edu Tue Feb 7 04:50:04 2006 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Mon, 06 Feb 2006 20:50:04 -0800 Subject: AVCs denied from latest FC4 kernel startup In-Reply-To: References: <1139174538.2401.5.camel@chaucer> Message-ID: <1139287804.2701.2.camel@chaucer> On Mon, 2006-02-06 at 15:00 -0500, Matthew Saltzman wrote: > On Sun, 5 Feb 2006, Bob Kashani wrote: > > > On Sat, 2006-02-04 at 23:35 -0500, Matthew Saltzman wrote: > >> After installing kernel-2.6.15-1.1830_FC4 (or any of the 2.6.15 kernels), > >> I get the following on startup. Startup appears to complete normally and > >> the system seems functional (at least for what I've tried so far). > >> > >> audit(1139113698.796:2): avc: denied { search } for pid=578 > >> comm="hotplug" name="proc" dev=dm-0 ino=851969 > >> scontext=system_u:system_r:hotplug_t > >> tcontext=system_u:object_r:unlabeled_t tclass=dir > > > > Matt, what's the context of /etc/hotplug and /sbin/hotplug? I have this: > > > > drwxr-xr-x root root > > system_u:object_r:hotplug_etc_t /etc/hotplug > > drwxr-xr-x root root > > system_u:object_r:etc_t /etc/hotplug.d > > -rwxr-xr-x root root > > system_u:object_r:hotplug_exec_t /sbin/hotplug > > > > Try /sbin/restorecon -R /etc/hotplug* /sbin/hotplug > > $ ls -dZ /etc/hotplug.* /sbin/hotplug > drwxr-xr-x root root system_u:object_r:etc_t /etc/hotplug.d > drwxr-xr-x root root system_u:object_r:hotplug_etc_t /etc/hotplug > -rwxr-xr-x root root system_u:object_r:hotplug_exec_t /sbin/hotplug > > After the restorecon, mine are the same as yours. The startup messages > are nto affected. > > BTW, I get the same startup messages in 2.6.14 FC4 kernels if I boot in > non-quiet mode. > > I filed a bug against the kernel as requested by Stephen Smalley. Try doing a full relabel to verify that everything is labeled correctly: touch /.autorelabel reboot Bob -- Bob Kashani GARNOME Project http://www.gnome.org/projects/garnome From saikiranrgda at gmail.com Tue Feb 7 05:03:15 2006 From: saikiranrgda at gmail.com (Sai Kiran) Date: Tue, 7 Feb 2006 10:33:15 +0530 Subject: selinux causes a problem with cdrom mounting on Fedora Core 3 In-Reply-To: References: Message-ID: <7c6561690602062103k7ea42cf3p3f0367e08d2b4374@mail.gmail.com> On 2/7/06, pine oil wrote: > > CD does not get mounted properly apparently due to SELinux as indicated in > the /etc/fstab as below. I edited the file to eliminated the entry made by > SELinux. On reboot, the same entry appears again. What do I do now? How did u come to the conclusion tht selinux is causing problem? > /dev/hdc /media/cdrom auto > pamconsole,fscontext=system_u:object_r:removable_t,ro,exec,noauto,managed > 0 0 The above entry basically sets the default context on removable fs . There is no problem as far as i see. Did u get any AVC denial errors.......... wht was the error u were getting? regards, kiran From sds at tycho.nsa.gov Tue Feb 7 13:29:25 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 07 Feb 2006 08:29:25 -0500 Subject: [kay.sievers@vrfy.org] In-Reply-To: <20060207011820.GC1660@vrfy.org> References: <20060206154605.GB32552@devserv.devel.redhat.com> <1139242448.31135.73.camel@moss-spartans.epoch.ncsc.mil> <43E79241.8010805@redhat.com> <1139250935.31135.129.camel@moss-spartans.epoch.ncsc.mil> <20060207011820.GC1660@vrfy.org> Message-ID: <1139318965.2872.28.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-02-07 at 02:18 +0100, Kay Sievers wrote: > The udev event processes, the ones that actually create the device node > are just clones of the main daemon, they run the same code, the same > memory as the main daemon, they don't exec() anything. So everything that > is available in the main daemon before the event process is forked, will > also be available in the event process itself while it is creating the > node. > > That's the reason I was asking, cause it sounds like the current selinux > integration could be optimized. Seems there is no need for any pipe or other > ipc, if selinux is fine with the inherited state from the daemon. Yes, in that case, performing the matchpathcon_init_prefix call once in the main daemon would likely be fine. -- Stephen Smalley National Security Agency From selinux at gmail.com Tue Feb 7 14:43:04 2006 From: selinux at gmail.com (Tom London) Date: Tue, 7 Feb 2006 06:43:04 -0800 Subject: crond execheap In-Reply-To: <43E81DD3.2050501@redhat.com> References: <4c4ba1530602051232k55348d26r861fd895593e6564@mail.gmail.com> <43E7B368.80704@redhat.com> <43E81DD3.2050501@redhat.com> Message-ID: <4c4ba1530602070643t3a8f62f0jf3983232ff8b7ce9@mail.gmail.com> Here it its. Should be 'latest rawhide'..... tom [root at localhost ~]# ls -lt /sbin/init -rwxr-xr-x 1 root root 36940 Dec 21 09:28 /sbin/init [root at localhost ~]# readelf -dl /sbin/init Elf file type is EXEC (Executable file) Entry point 0x8049a70 There are 8 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x08048034 0x08048034 0x00100 0x00100 R E 0x4 INTERP 0x000134 0x08048134 0x08048134 0x00013 0x00013 R 0x1 [Requesting program interpreter: /lib/ld-linux.so.2] LOAD 0x000000 0x08048000 0x08048000 0x07f9a 0x07f9a R E 0x1000 LOAD 0x008000 0x08050000 0x08050000 0x00510 0x00714 RW 0x1000 DYNAMIC 0x008014 0x08050014 0x08050014 0x000d8 0x000d8 RW 0x4 NOTE 0x000148 0x08048148 0x08048148 0x00020 0x00020 R 0x4 GNU_EH_FRAME 0x007530 0x0804f530 0x0804f530 0x00008 0x00008 R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.ABI-tag .hash .dynsym .gnu.liblist .gnu.conflict .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame .dynstr 03 .ctors .dtors .jcr .dynamic .got .got.plt .data .dynbss .bss 04 .dynamic 05 .note.ABI-tag 06 .eh_frame_hdr 07 Dynamic section at offset 0x8014 contains 26 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libsepol.so.1] 0x00000001 (NEEDED) Shared library: [libselinux.so.1] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x0000000c (INIT) 0x8049448 0x0000000d (FINI) 0x804ebe0 0x00000004 (HASH) 0x8048168 0x00000005 (STRTAB) 0x804fb5c 0x00000006 (SYMTAB) 0x80484b0 0x0000000a (STRSZ) 1056 (bytes) 0x0000000b (SYMENT) 16 (bytes) 0x00000015 (DEBUG) 0x0 0x00000003 (PLTGOT) 0x80500f0 0x00000002 (PLTRELSZ) 768 (bytes) 0x00000014 (PLTREL) REL 0x00000017 (JMPREL) 0x8049148 0x00000011 (REL) 0x8049120 0x00000012 (RELSZ) 40 (bytes) 0x00000013 (RELENT) 8 (bytes) 0x6ffffffe (VERNEED) 0x80490a0 0x6fffffff (VERNEEDNUM) 1 0x6ffffff0 (VERSYM) 0x8048fc0 0x6ffffef9 (GNU_LIBLIST) 0x8048ba0 0x6ffffdf7 (GNU_LIBLISTSZ) 100 (bytes) 0x6ffffef8 (GNU_CONFLICT) 0x8048c04 0x6ffffdf6 (GNU_CONFLICTSZ) 288 (bytes) 0x00000000 (NULL) 0x0 From dwalsh at redhat.com Tue Feb 7 14:55:17 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 07 Feb 2006 09:55:17 -0500 Subject: [kay.sievers@vrfy.org] In-Reply-To: <20060207011820.GC1660@vrfy.org> References: <20060206154605.GB32552@devserv.devel.redhat.com> <1139242448.31135.73.camel@moss-spartans.epoch.ncsc.mil> <43E79241.8010805@redhat.com> <1139250935.31135.129.camel@moss-spartans.epoch.ncsc.mil> <20060207011820.GC1660@vrfy.org> Message-ID: <43E8B4D5.8050800@redhat.com> Kay Sievers wrote: > On Mon, Feb 06, 2006 at 01:35:35PM -0500, Stephen Smalley wrote: > >> On Mon, 2006-02-06 at 13:15 -0500, Daniel J Walsh wrote: >> >>> How about if we changed the call to >>> if ( mode & S_IFBLK ) { >>> media = get_media(devname, mode); >>> if (media) { >>> ret = matchmediacon(media, &scontext); >>> free(media); >>> } >>> } >>> >> You already have a test of (mode & S_IFBLK) on entry to get_media, so I >> don't see what that buys you. Still limited to ide devices by get_media >> only checking /proc/ide. I don't think her concern with the media >> support was performance, just generality and use of sysfs. Performance >> concern was with selinux_init. >> >> On the performance overhead issue, only real improvement would be to >> move all matchpathcon_init+matchpathcon processing into the daemon and >> have the daemon pass the required contexts to the event commands on the >> command line or via pipe. >> > > The udev event processes, the ones that actually create the device node > are just clones of the main daemon, they run the same code, the same > memory as the main daemon, they don't exec() anything. So everything that > is available in the main daemon before the event process is forked, will > also be available in the event process itself while it is creating the > node. > > That's the reason I was asking, cause it sounds like the current selinux > integration could be optimized. Seems there is no need for any pipe or other > ipc, if selinux is fine with the inherited state from the daemon. > > Thanks, > Kay > Yes I think it would should work fine. I think a patch like the following should also be added to udev_selinux. - media = get_media(devname, mode); - if (media) { - ret = matchmediacon(media, &scontext); - free(media); + if ( mode & S_IFBLK ) { + media = get_media(devname, mode); + if (media) { + ret = matchmediacon(media, &scontext); + free(media); + } } From notting at redhat.com Tue Feb 7 16:51:40 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Feb 2006 11:51:40 -0500 Subject: [kay.sievers@vrfy.org] In-Reply-To: <20060207164403.GA11731@vrfy.org> References: <20060206154605.GB32552@devserv.devel.redhat.com> <1139242448.31135.73.camel@moss-spartans.epoch.ncsc.mil> <43E79241.8010805@redhat.com> <1139250935.31135.129.camel@moss-spartans.epoch.ncsc.mil> <20060207011820.GC1660@vrfy.org> <43E8B4D5.8050800@redhat.com> <20060207164403.GA11731@vrfy.org> Message-ID: <20060207165139.GA12709@devserv.devel.redhat.com> Kay Sievers (kay.sievers at vrfy.org) said: > Heh, yeah, that looks fine, but I asked for more :) > > o What about other media than ide? How is that different? > (I don't have a single box left with old ide drivers) For SCSI, etc., the media type is easily determined from the device name - for IDE it's not. (At least, I presume that's the reason.) Bill From notting at redhat.com Tue Feb 7 22:37:50 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Feb 2006 17:37:50 -0500 Subject: unionfs, tmpfs, and xattrs Message-ID: <20060207223750.GB26885@devserv.devel.redhat.com> So, I'm playing some with unionfs (http://www.fsl.cs.sunysb.edu/project-unionfs.html), which works fine with SELinux as long as the underlying filesystems that you're using in the union all support xattrs. Which brings us to tmpfs. The way xattrs appear to work on tmpfs is that the VFS tries the getxattr op of tmpfs (which fails, as it doesn't exist), and then does an end-run around in the selinux code to get an attribute, as long as you're only looking for the security xattr. This means that anything on tmpfs can have a xattr retrieved from userspace just fine with getxattr(2), but if you try and get it in the kernel via 'normal' means (such as the inode's getxattr method), it will fail. This breaks tmpfs as part of a unionfs branch pretty badly. Why was xattrs-on-tmpfs done this way? It seems somewhat hackish. I could theoretically patch unionfs to call the vfs method, but... ew. Bill From jmorris at namei.org Tue Feb 7 23:26:02 2006 From: jmorris at namei.org (James Morris) Date: Tue, 7 Feb 2006 18:26:02 -0500 (EST) Subject: unionfs, tmpfs, and xattrs In-Reply-To: <20060207223750.GB26885@devserv.devel.redhat.com> References: <20060207223750.GB26885@devserv.devel.redhat.com> Message-ID: On Tue, 7 Feb 2006, Bill Nottingham wrote: > The way xattrs appear to work on tmpfs is that the VFS tries the getxattr > op of tmpfs (which fails, as it doesn't exist), and then does an end-run > around in the selinux code to get an attribute, as long as you're only > looking for the security xattr. What it's doing is checking if the fs can supply a security xattr, and if not, allows the kernel to supply one. > This means that anything on tmpfs can have a xattr retrieved from userspace > just fine with getxattr(2), but if you try and get it in the kernel via > 'normal' means (such as the inode's getxattr method), it will fail. This > breaks tmpfs as part of a unionfs branch pretty badly. > > Why was xattrs-on-tmpfs done this way? It seems somewhat hackish. So xattrs do not have to be implemented for every type of psudo fs. What is the upstream status of unionfs? > I could theoretically patch unionfs to call the vfs method, but... ew. -- James Morris From notting at redhat.com Wed Feb 8 03:44:26 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Feb 2006 22:44:26 -0500 Subject: unionfs, tmpfs, and xattrs In-Reply-To: References: <20060207223750.GB26885@devserv.devel.redhat.com> Message-ID: <20060208034425.GA16440@devserv.devel.redhat.com> James Morris (jmorris at namei.org) said: > > This means that anything on tmpfs can have a xattr retrieved from userspace > > just fine with getxattr(2), but if you try and get it in the kernel via > > 'normal' means (such as the inode's getxattr method), it will fail. This > > breaks tmpfs as part of a unionfs branch pretty badly. > > > > Why was xattrs-on-tmpfs done this way? It seems somewhat hackish. > > So xattrs do not have to be implemented for every type of psudo fs. Well, yes, but it means the xattrs implemented for these pseudo fses are somewhat incomplete, if not broken. Can you, in the kernel, easily check to see if xattrs are supported for a filesystem? No. Can you, in userspace, remove xattrs? No. It just seems like a hacky interface to say "filesystems need to provide their own xattr code, but if they don't the security module might decide to make one up." It would seem preferable to just have the security labels be done via an explicit mechanism rather than to incompletely overload xattrs. > What is the upstream status of unionfs? It's not upstream yet, although it's used in a variety of projects. Moreover, trying to fix it to work around this, doesn't work, as... > > I could theoretically patch unionfs to call the vfs method, but... ew. listxattr isn't exported as a vfs method, and even just using the vfs_get/setxattr methods doesn't appear to work correctly. Bill From sds at tycho.nsa.gov Wed Feb 8 13:03:36 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 08 Feb 2006 08:03:36 -0500 Subject: unionfs, tmpfs, and xattrs In-Reply-To: <20060208034425.GA16440@devserv.devel.redhat.com> References: <20060207223750.GB26885@devserv.devel.redhat.com> <20060208034425.GA16440@devserv.devel.redhat.com> Message-ID: <1139403816.2872.109.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-02-07 at 22:44 -0500, Bill Nottingham wrote: > Well, yes, but it means the xattrs implemented for these pseudo fses > are somewhat incomplete, if not broken. > > Can you, in the kernel, easily check to see if xattrs are supported for a > filesystem? No. SELinux xattrs are _always_ supported for every filesystem by definition, because their values are actually provided by the SELinux module. All data must be labeled. > Can you, in userspace, remove xattrs? No. Removal of SELinux xattrs (or more generally, MAC labels) is not allowed, even for conventional filesystems like ext3, as long as SELinux is operating/enabled. No unlabeled data. > > It just seems like a hacky interface to say "filesystems need to provide their > own xattr code, but if they don't the security module might decide to make one up." > It would seem preferable to just have the security labels be done via an > explicit mechanism rather than to incompletely overload xattrs. I think you need to look at the history here: We started with our own APIs for SELinux separate from the xattr API, but were told to migrate to using the xattr API for upstream merging of SELinux into Linux 2.6. We then individually patched various filesystems like tmpfs and devpts on an as-needed basis to support the security xattrs, but the real processing for such filesystems simply consisted of calling back into the SELinux module to get/set the incore inode security information. For LSPP (and as a widely desired functional enhancement by people who wanted to see labels on other filesystems like /proc and were used to being able to do that with the old SELinux), we needed to support at least the ability to get the security attributes on all filesystem types (and to get the actual security attribute as seen by SELinux, including for filesystems labeled via context mounts, genfs_contexts, etc). So we introduced a generic fallback for security xattrs in the VFS in 2.6.14 so that we didn't need to patch every filesystem type, and then we introduced support for canonicalization of getxattr results in 2.6.15 so that userspace could see the same label being used actively by SELinux. > > What is the upstream status of unionfs? > > It's not upstream yet, although it's used in a variety of projects. > Moreover, trying to fix it to work around this, doesn't work, as... Over on redhat-lspp, during early discussions of polyinstantiated directories and potential use of unionfs there, Viro said that unionfs was nowhere near ready for merging and had a lot of nasty corner cases. > > > > I could theoretically patch unionfs to call the vfs method, but... ew. > > listxattr isn't exported as a vfs method, and even just using the vfs_get/setxattr > methods doesn't appear to work correctly. Not sure what issue you are encountering with using vfs_getxattr; nfsd uses it. For listxattr, introducing a vfs_listxattr should be straightforward and reasonable if there is a user for it; I think the absence is just due to a lack of a user. -- Stephen Smalley National Security Agency From goeran at uddeborg.se Wed Feb 8 13:32:16 2006 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran_Uddeborg?=) Date: Wed, 8 Feb 2006 14:32:16 +0100 Subject: What makes contexts different for audit.log and ls -Z? Message-ID: <17385.62176.137014.39091@mimmi.uddeborg.se> What could cause the context shown with "ls" and the context reported for an denied AVC check to differ? After a recent upgrade, Samba stopped working for us. Trying smbclient user adb is not allowed to access it's home directory. From an strace of smbd I see that a stat() call fails: 8307 stat64("/home/adb", 0xbff08334) = -1 EACCES (Permission denied) I believe I found the reason in audit.log: type=AVC msg=audit(1139403413.095:1782): avc: denied { search } for pid=8647 comm="smbd" name="home" dev=hda2 ino=966657 scontext=root:system_r:smbd_t tcontext=system_u:object_r:home_root_t tclass=dir type=SYSCALL msg=audit(1139403413.095:1782): arch=40000003 syscall=195 success=no exit=-13 a0=90f7110 a1=bff08334 a2=5baff4 a3=bff08334 items=1 pid=8647 auid=504 uid=734 gid=0 euid=734 suid=0 fsuid=734 egid=734 sgid=734 fsgid=734 comm="smbd" exe="/usr/sbin/smbd" type=CWD msg=audit(1139403413.095:1782): cwd="/" type=PATH msg=audit(1139403413.095:1782): item=0 name="/home/adb" flags=1 inode=966657 dev=03:02 mode=040755 ouid=0 ogid=0 rdev=00:00 "home_root_t" for /home/adb seems incorrect to me. But when I do ls -ldZ on /home/adb, it has a different context: server2# ls -lZd /home/adb drwx------ adb adb user_u:object_r:user_home_dir_t /home/adb "user_home_dir_t" makes a lot more sense. The context of the smbd daemon looks right with ps. server2$ ps -ZC smbd LABEL PID TTY TIME CMD root:system_r:smbd_t 7737 ? 00:00:00 smbd root:system_r:smbd_t 7735 ? 00:00:00 smbd Somewhat blindly, I have done a "fixfiles -F relabel", and I've done an extra "load_policy?policy.19", and neither makes any difference. From tmerritt at email.arizona.edu Wed Feb 8 13:37:47 2006 From: tmerritt at email.arizona.edu (Todd Merritt) Date: Wed, 08 Feb 2006 06:37:47 -0700 Subject: What makes contexts different for audit.log and ls -Z? In-Reply-To: <17385.62176.137014.39091@mimmi.uddeborg.se> References: <17385.62176.137014.39091@mimmi.uddeborg.se> Message-ID: <43E9F42B.70803@email.arizona.edu> You need to be able to search / to find /home. G?ran Uddeborg wrote: > What could cause the context shown with "ls" and the context reported > for an denied AVC check to differ? > > After a recent upgrade, Samba stopped working for us. Trying > smbclient user adb is not allowed to access it's home directory. From > an strace of smbd I see that a stat() call fails: > > 8307 stat64("/home/adb", 0xbff08334) = -1 EACCES (Permission denied) > > I believe I found the reason in audit.log: > > type=AVC msg=audit(1139403413.095:1782): avc: denied { search } for pid=8647 comm="smbd" name="home" dev=hda2 ino=966657 scontext=root:system_r:smbd_t tcontext=system_u:object_r:home_root_t tclass=dir > type=SYSCALL msg=audit(1139403413.095:1782): arch=40000003 syscall=195 success=no exit=-13 a0=90f7110 a1=bff08334 a2=5baff4 a3=bff08334 items=1 pid=8647 auid=504 uid=734 gid=0 euid=734 suid=0 fsuid=734 egid=734 sgid=734 fsgid=734 comm="smbd" exe="/usr/sbin/smbd" > type=CWD msg=audit(1139403413.095:1782): cwd="/" > type=PATH msg=audit(1139403413.095:1782): item=0 name="/home/adb" flags=1 inode=966657 dev=03:02 mode=040755 ouid=0 ogid=0 rdev=00:00 > > "home_root_t" for /home/adb seems incorrect to me. But when I do ls > -ldZ on /home/adb, it has a different context: > > server2# ls -lZd /home/adb > drwx------ adb adb user_u:object_r:user_home_dir_t /home/adb > > "user_home_dir_t" makes a lot more sense. > > The context of the smbd daemon looks right with ps. > > server2$ ps -ZC smbd > LABEL PID TTY TIME CMD > root:system_r:smbd_t 7737 ? 00:00:00 smbd > root:system_r:smbd_t 7735 ? 00:00:00 smbd > > Somewhat blindly, I have done a "fixfiles -F relabel", and I've done > an extra "load_policy policy.19", and neither makes any difference. > > -- > 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 Wed Feb 8 13:51:05 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 08 Feb 2006 08:51:05 -0500 Subject: What makes contexts different for audit.log and ls -Z? In-Reply-To: <17385.62176.137014.39091@mimmi.uddeborg.se> References: <17385.62176.137014.39091@mimmi.uddeborg.se> Message-ID: <1139406665.2872.116.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-02-08 at 14:32 +0100, G?ran Uddeborg wrote: > What could cause the context shown with "ls" and the context reported > for an denied AVC check to differ? > > After a recent upgrade, Samba stopped working for us. Trying > smbclient user adb is not allowed to access it's home directory. From > an strace of smbd I see that a stat() call fails: > > 8307 stat64("/home/adb", 0xbff08334) = -1 EACCES (Permission denied) > > I believe I found the reason in audit.log: > > type=AVC msg=audit(1139403413.095:1782): avc: denied { search } for pid=8647 comm="smbd" name="home" dev=hda2 ino=966657 scontext=root:system_r:smbd_t tcontext=system_u:object_r:home_root_t tclass=dir > type=SYSCALL msg=audit(1139403413.095:1782): arch=40000003 syscall=195 success=no exit=-13 a0=90f7110 a1=bff08334 a2=5baff4 a3=bff08334 items=1 pid=8647 auid=504 uid=734 gid=0 euid=734 suid=0 fsuid=734 egid=734 sgid=734 fsgid=734 comm="smbd" exe="/usr/sbin/smbd" > type=CWD msg=audit(1139403413.095:1782): cwd="/" > type=PATH msg=audit(1139403413.095:1782): item=0 name="/home/adb" flags=1 inode=966657 dev=03:02 mode=040755 ouid=0 ogid=0 rdev=00:00 If you look closely at the AVC audit message (which admittedly is inscrutable ;), you'll see that the component on which search failed was for "home", not "/home/adb". You have to be able to search /home to reach /home/adb. Try 'man samba_selinux' and following the instructions there for modifying the relevant boolean. -- Stephen Smalley National Security Agency From jmorris at namei.org Wed Feb 8 14:51:48 2006 From: jmorris at namei.org (James Morris) Date: Wed, 8 Feb 2006 09:51:48 -0500 (EST) Subject: unionfs, tmpfs, and xattrs In-Reply-To: <20060208034425.GA16440@devserv.devel.redhat.com> References: <20060207223750.GB26885@devserv.devel.redhat.com> <20060208034425.GA16440@devserv.devel.redhat.com> Message-ID: On Tue, 7 Feb 2006, Bill Nottingham wrote: > It just seems like a hacky interface to say "filesystems need to provide their > own xattr code, but if they don't the security module might decide to make one up." It doesn't "make one up", the kernel has an xattr because the data is always labeled. What it's saying is, if the fs doesn't implement it's own xattr code, we return what the kernel is maintaining anyway. > It would seem preferable to just have the security labels be done via an > explicit mechanism rather than to incompletely overload xattrs. It is explicit, but there's a fallback if the fs doesn't implement xattrs. You can still override this by implementing xattrs for a psuedo fs. > > > What is the upstream status of unionfs? > > It's not upstream yet, although it's used in a variety of projects. It's really best for everyone if the code is posted for upstream merge. - James -- James Morris From notting at redhat.com Wed Feb 8 15:44:32 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 8 Feb 2006 10:44:32 -0500 Subject: unionfs, tmpfs, and xattrs In-Reply-To: <1139403816.2872.109.camel@moss-spartans.epoch.ncsc.mil> References: <20060207223750.GB26885@devserv.devel.redhat.com> <20060208034425.GA16440@devserv.devel.redhat.com> <1139403816.2872.109.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20060208154432.GA31552@devserv.devel.redhat.com> Stephen Smalley (sds at tycho.nsa.gov) said: > > Can you, in the kernel, easily check to see if xattrs are supported for a > > filesystem? No. > > SELinux xattrs are _always_ supported for every filesystem by > definition, because their values are actually provided by the SELinux > module. All data must be labeled. Then the filesystem should have a getxattr() method... that's all that I'm saying here. Having filesystems that return xattrs, but, claim they don't in their own methods, is somewhat disingenious. > > > > I could theoretically patch unionfs to call the vfs method, but... ew. > > > > listxattr isn't exported as a vfs method, and even just using the vfs_get/setxattr > > methods doesn't appear to work correctly. > > Not sure what issue you are encountering with using vfs_getxattr; nfsd > uses it. Locks. Could be some other stuck locks, will investigate some more. > For listxattr, introducing a vfs_listxattr should be > straightforward and reasonable if there is a user for it; I think the > absence is just due to a lack of a user. If we're going to have the filesystem's own getxattr() methods not actually tell whether the FS returns an xattr, I think wrapping all the calls is needed... Bill From goeran at uddeborg.se Wed Feb 8 15:54:27 2006 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran_Uddeborg?=) Date: Wed, 8 Feb 2006 16:54:27 +0100 Subject: What makes contexts different for audit.log and ls -Z? In-Reply-To: <1139406665.2872.116.camel@moss-spartans.epoch.ncsc.mil> References: <17385.62176.137014.39091@mimmi.uddeborg.se> <1139406665.2872.116.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <17386.5171.468561.696870@mimmi.uddeborg.se> Stephen Smalley writes: > If you look closely at the AVC audit message (which admittedly is > inscrutable ;), you'll see that the component on which search failed was > for "home", not "/home/adb". Aha, the PATH audit entry doesn't mean what I thought it meant. Guess I should have checked the inode too. Thanks for the pointer, it works now! :-) From DVerbeeck at LIO.AACISD.com Wed Feb 8 19:37:40 2006 From: DVerbeeck at LIO.AACISD.com (Verbeeck Derek) Date: Wed, 8 Feb 2006 14:37:40 -0500 Subject: auditing support for FC2 w/ kernel 2.6.10-1.771_FC2 Message-ID: <4CE2D801AFDA594D8FB3E4F35206E837123FB8@EXNY.us.corp.aacisd.com> Greetings, I'm trying to get audit support working w/ FC2 and kernel 2.6.10 (provided from a yum repository and recompiled from that source). The issue is that even when both audit support and syscall auditing are flagged on in .config, when the system is booting with a rebuilt kernel, I am not seeing a /dev/audit device file, so the audit software I'm trying to use fails. I'm trying to use laus, a third party application written by Novell, which builds fine from source, but fails due to lack of /dev/audit. I have tried to mknod the device file myself with no success, it still complains about not having the audit device. Does anyone have experience with a similar scenario? Am I going about this the wrong way? Thanks for your time! Derek Verbeeck System Administrator Advanced Acoustic Concepts 631-273-5700 ext 2305 -------------- next part -------------- An HTML attachment was scrubbed... URL: From linux_4ever at yahoo.com Wed Feb 8 20:56:20 2006 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 8 Feb 2006 12:56:20 -0800 (PST) Subject: auditing support for FC2 w/ kernel 2.6.10-1.771_FC2 In-Reply-To: <4CE2D801AFDA594D8FB3E4F35206E837123FB8@EXNY.us.corp.aacisd.com> Message-ID: <20060208205620.61189.qmail@web51505.mail.yahoo.com> >Does anyone have experience with a similar scenario? Am I going about this the >wrong way? Yep. What you are talking about is laus - which is a Suse audit system. The 2.6 kernel has a native audit system that works completely different from Laus. The user space package can be found at http://people.redhat.com/sgrubb/audit. The latest stable version is 1.0.14. I want to think that you need 2.6.14 kernel to have most problems solved. You can try the older kernel and if you run into problems you should look for something newer. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From linux at linuon.com Thu Feb 9 06:13:08 2006 From: linux at linuon.com (Junji Kanemaru) Date: Thu, 09 Feb 2006 15:13:08 +0900 Subject: shared lib problem Message-ID: <43EADD74.2020906@linuon.com> Hi, I'm having problem with fc5-test2 that my app fails to load its own shared library. The error I'm getting is: "cannot restore segment prot after reloc: Permission denied" It only happens when /selinux/enforce is true. I changed security context of the shared library but same... Any clue? If more info needed then let me know what kind of info are needed. Thanks, -- Junji -- Junji Kanemaru Linuon Inc. Tokyo Japan From mennis309 at gmail.com Thu Feb 9 07:37:01 2006 From: mennis309 at gmail.com (Mark Ennis) Date: Thu, 9 Feb 2006 18:37:01 +1100 Subject: shared lib problem In-Reply-To: <43EADD74.2020906@linuon.com> References: <43EADD74.2020906@linuon.com> Message-ID: See: http://people.redhat.com/drepper/selinux-mem.html http://people.redhat.com/drepper/dsohowto.pdf On 2/9/06, Junji Kanemaru wrote: > Hi, > > I'm having problem with fc5-test2 that my app fails to load its > own shared library. The error I'm getting is: > > "cannot restore segment prot after reloc: Permission denied" > > It only happens when /selinux/enforce is true. I changed > security context of the shared library but same... Any clue? > > If more info needed then let me know what kind of info are > needed. > > Thanks, > -- Junji > > -- > Junji Kanemaru > Linuon Inc. > Tokyo Japan > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From aiasgreat at gmail.com Thu Feb 9 09:19:51 2006 From: aiasgreat at gmail.com (Achilles Myrmidon) Date: Thu, 9 Feb 2006 11:19:51 +0200 Subject: Good morning from Greece Message-ID: <632d02a40602090119y5857da95t5c62fc4802698429@mail.gmail.com> I am a new user in Linux environment. I bought a new computer and it was about to install Fedora Core 4. I have inserted the first CD and i have choosen the option of "graphical installation". When i pressed the button "enter" i saw a screen with many numbers and some errors messages that i didn't write them down. My computer is new with EIDE and SATA II hard disks, with MSI GeForce graphical card and Intel CPU. Can you advise me please what could be wrong? Best Regards John -------------- next part -------------- An HTML attachment was scrubbed... URL: From srinivasa at in.ibm.com Thu Feb 9 09:31:46 2006 From: srinivasa at in.ibm.com (srinivasa) Date: Thu, 09 Feb 2006 15:01:46 +0530 Subject: dbus error message In-Reply-To: <20060118140820.51904.qmail@web51509.mail.yahoo.com> References: <20060118140820.51904.qmail@web51509.mail.yahoo.com> Message-ID: <43EB0C02.2090304@in.ibm.com> Steve G wrote: >>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. > > > Thank you Steve for your reply. I heard that you already have the patch for Fedora which causes the dbus to retain capabality after changing from root to dbus user. Can you please give that patch or send the link containing the patch so that I will test it on my Fedora machine. >>>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 linux at linuon.com Thu Feb 9 09:45:46 2006 From: linux at linuon.com (Junji Kanemaru) Date: Thu, 09 Feb 2006 18:45:46 +0900 Subject: shared lib problem In-Reply-To: References: <43EADD74.2020906@linuon.com> Message-ID: <43EB0F4A.2070000@linuon.com> Thanks for the info. Actually, it worked with texrel_shlib_t. Don't know if it is right solution or not... I briefly read the site but still not sure what the real solution is. I wonder if the error is pointing there's some fundamental bugs lurk in my code. There are no writable variables in shared libraries but almost all code have been written in C++. Is it affecting for some reason? I had no problems with SELinux targeted policy in fc4. Please enlighten me. Thanks, -- Junji Mark Ennis wrote: > See: > http://people.redhat.com/drepper/selinux-mem.html > http://people.redhat.com/drepper/dsohowto.pdf > > On 2/9/06, Junji Kanemaru wrote: > >>Hi, >> >>I'm having problem with fc5-test2 that my app fails to load its >>own shared library. The error I'm getting is: >> >>"cannot restore segment prot after reloc: Permission denied" >> >>It only happens when /selinux/enforce is true. I changed >>security context of the shared library but same... Any clue? >> >>If more info needed then let me know what kind of info are >>needed. >> >>Thanks, >>-- Junji >> >>-- >>Junji Kanemaru >>Linuon Inc. >>Tokyo Japan >> >>-- >>fedora-selinux-list mailing list >>fedora-selinux-list at redhat.com >>https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > > -- Junji Kanemaru Linuon Inc. Tokyo Japan From paul at city-fan.org Thu Feb 9 10:53:14 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 09 Feb 2006 10:53:14 +0000 Subject: Good morning from Greece In-Reply-To: <632d02a40602090119y5857da95t5c62fc4802698429@mail.gmail.com> References: <632d02a40602090119y5857da95t5c62fc4802698429@mail.gmail.com> Message-ID: <43EB1F1A.30905@city-fan.org> Achilles Myrmidon wrote: > I am a new user in Linux environment. I bought a new computer and it was > about to install Fedora Core 4. I have inserted the first CD and i have > choosen the option of "graphical installation". When i pressed the > button "enter" i saw a screen with many numbers and some errors messages > that i didn't write them down. > My computer is new with EIDE and SATA II hard disks, with MSI GeForce > graphical card and Intel CPU. > > Can you advise me please what could be wrong? This is the wrong mailing list for this type of question. Please try fedora-list next time. The following link may help you: http://fedoranews.org/mediawiki/index.php/FC4_CD/DVD_Installer_Syslinux_Crash_Workaround Paul. From linux_4ever at yahoo.com Thu Feb 9 13:58:09 2006 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 9 Feb 2006 05:58:09 -0800 (PST) Subject: dbus error message In-Reply-To: <43EB0C02.2090304@in.ibm.com> Message-ID: <20060209135809.81962.qmail@web51511.mail.yahoo.com> >I heard that you already have the patch for Fedora which causes the dbus to > retain capabality after changing from root to dbus user. >Can you please give that patch or send the link containing the patch so >that I will test it on my Fedora machine Sure. Its here: http://people.redhat.com/sgrubb/files/dbus-0.60-selinux-avc-audit.patch I'll leave it there for a few days, but it'll eventually get removed. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From gajownik at fedora.pl Thu Feb 9 14:19:37 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Thu, 09 Feb 2006 15:19:37 +0100 Subject: shared lib problem In-Reply-To: <43EB0F4A.2070000@linuon.com> References: <43EADD74.2020906@linuon.com> <43EB0F4A.2070000@linuon.com> Message-ID: <43EB4F79.5000700@fedora.pl> Dnia 02/09/2006 10:47 AM, U?ytkownik Junji Kanemaru napisa?: > Actually, it worked with texrel_shlib_t. Don't know if it is right > solution or not... It's just a workaround. It would be better to get rid of text relocations because they're evil ;) http://thread.gmane.org/gmane.linux.gentoo.devel/33992 http://article.gmane.org/gmane.linux.gentoo.devel/34037 > There are no writable variables in shared libraries but almost all > code have been written in C++. This can be a bug in gcc: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175275 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175442 or you missed -fpic/-fPIC option when compiling your coftware http://www.gentoo.org/proj/en/hardened/pic-guide.xml http://www.gentoo.org/proj/en/hardened/pic-internals.xml http://www.gentoo.org/proj/en/hardened/pic-fix-guide.xml Hope that helps. Regards, Dawid -- ^_* From linux at linuon.com Thu Feb 9 15:11:10 2006 From: linux at linuon.com (Junji Kanemaru) Date: Fri, 10 Feb 2006 00:11:10 +0900 Subject: shared lib problem In-Reply-To: <43EB4F79.5000700@fedora.pl> References: <43EADD74.2020906@linuon.com> <43EB0F4A.2070000@linuon.com> <43EB4F79.5000700@fedora.pl> Message-ID: <43EB5B8E.701@linuon.com> > or you missed -fpic/-fPIC option when compiling your coftware I missed it. After I added -fPIC the avc error has gone. But now dlopen() fails. dlerror() says: "No such file or directory" The shared libraries that my app is loading are plugins. They are not linked with main app. they are loaded on demand and resolved symbols on the fly. Do I need some tweaking with them? -- junji -- Junji Kanemaru Linuon Inc. Tokyo Japan From drepper at redhat.com Thu Feb 9 15:49:18 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Thu, 09 Feb 2006 07:49:18 -0800 Subject: shared lib problem In-Reply-To: <43EB0F4A.2070000@linuon.com> References: <43EADD74.2020906@linuon.com> <43EB0F4A.2070000@linuon.com> Message-ID: <43EB647E.4090406@redhat.com> Junji Kanemaru wrote: > There are no writable variables in shared libraries but almost all > code have been written in C++. Is it affecting for some reason? > I had no problems with SELinux targeted policy in fc4. The latter is not surprising. The problems arise due to new tests which were not in FC4. But the tests are not at fault. If you use C++ your code might be clean (you'll have to check that carefully) and there still can be problems: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175442 Unfortunately I don't see a fix on the horizon yet. -- ? 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 markus.lindholm at gmail.com Thu Feb 9 19:10:08 2006 From: markus.lindholm at gmail.com (Markus Lindholm) Date: Thu, 9 Feb 2006 20:10:08 +0100 Subject: Need help with moving the data directory of Postgresql Message-ID: <6168d00f0602091110u5aabce7ald7e533850cb3f917@mail.gmail.com> Hi I have a FC4 box (all updates applied) on which I have a Postgresql server (standard fedora rpms) and I'm running targeted selinux policy. The problem is that I cannot move the data directory away from /var/lib/pgsql/data with out turning selinux off. Is there any HOWTOs out there that would be helpful? I've tried using chcon so that the permission would be identical between the new and the old [root at zeus ~]# ls -ldZ /var/lib/pgsql/data/ drwx------ postgres postgres system_u:object_r:postgresql_db_t /var/lib/pgsql/data/ [root at zeus ~]# ls -lZd /mnt/raid/db/pgsql/data/ drwx------ postgres postgres system_u:object_r:postgresql_db_t /mnt/raid/db/pgsql/data/ But I still get permission denied when I try to start postgresql !! If I mark the "Disable SELinux protection for Postgresql daemon" in the SELinux GUI, then it starts up fine. But what would be the correct way to handle this? /markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Thu Feb 9 20:13:01 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 09 Feb 2006 15:13:01 -0500 Subject: My thoughts on SELinux and AppArmor Message-ID: <43EBA24D.9000503@redhat.com> http://danwalsh.livejournal.com/ From dwalsh at redhat.com Thu Feb 9 20:23:12 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 09 Feb 2006 15:23:12 -0500 Subject: Need help with moving the data directory of Postgresql In-Reply-To: <6168d00f0602091110u5aabce7ald7e533850cb3f917@mail.gmail.com> References: <6168d00f0602091110u5aabce7ald7e533850cb3f917@mail.gmail.com> Message-ID: <43EBA4B0.6030905@redhat.com> Markus Lindholm wrote: > Hi > > I have a FC4 box (all updates applied) on which I have a Postgresql > server (standard fedora rpms) and I'm running targeted selinux policy. > The problem is that I cannot move the data directory away from > /var/lib/pgsql/data with out turning selinux off. > > Is there any HOWTOs out there that would be helpful? > > I've tried using chcon so that the permission would be identical > between the new and the old > > [root at zeus ~]# ls -ldZ /var/lib/pgsql/data/ > drwx------ postgres postgres system_u:object_r:postgresql_db_t > /var/lib/pgsql/data/ > [root at zeus ~]# ls -lZd /mnt/raid/db/pgsql/data/ > drwx------ postgres postgres system_u:object_r:postgresql_db_t > /mnt/raid/db/pgsql/data/ > > But I still get permission denied when I try to start postgresql !! If > I mark the "Disable SELinux protection for Postgresql daemon" in the > SELinux GUI, then it starts up fine. > But what would be the correct way to handle this? > What avc messages are you seeing? > /markus > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From DVerbeeck at LIO.AACISD.com Thu Feb 9 21:20:18 2006 From: DVerbeeck at LIO.AACISD.com (Verbeeck Derek) Date: Thu, 9 Feb 2006 16:20:18 -0500 Subject: auditing support for FC2 w/ kernel 2.6.10-1.771_FC2 Message-ID: <4CE2D801AFDA594D8FB3E4F35206E837123FC4@EXNY.us.corp.aacisd.com> Steve, I've had zero success with any of the releases on that page. Machine is running the stock gcc that shipped w/ FC2 and the updated 2.6.10 kernel, and I also tried it on a replica of this machine running 2.6.15.1. The make fails out on a bunch of calls to some functions. The site mentions needing updated glibc-kernel headers, but can these even be safely updated without hosing the system? Trying to find the least painful way to get auditing support on these systems. Neither laus, the built-in kernel auditing support with these user space packages, or SNARE seem to work. -Derek -----Original Message----- From: Steve G [mailto:linux_4ever at yahoo.com] Sent: Wednesday, February 08, 2006 3:56 PM To: Verbeeck Derek; fedora-selinux-list at redhat.com Subject: Re: auditing support for FC2 w/ kernel 2.6.10-1.771_FC2 >Does anyone have experience with a similar scenario? Am I going about this the >wrong way? Yep. What you are talking about is laus - which is a Suse audit system. The 2.6 kernel has a native audit system that works completely different from Laus. The user space package can be found at http://people.redhat.com/sgrubb/audit. The latest stable version is 1.0.14. I want to think that you need 2.6.14 kernel to have most problems solved. You can try the older kernel and if you run into problems you should look for something newer. -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 Thu Feb 9 21:40:24 2006 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 9 Feb 2006 13:40:24 -0800 (PST) Subject: auditing support for FC2 w/ kernel 2.6.10-1.771_FC2 In-Reply-To: <4CE2D801AFDA594D8FB3E4F35206E837123FC4@EXNY.us.corp.aacisd.com> Message-ID: <20060209214024.18303.qmail@web51505.mail.yahoo.com> >The make fails out on a bunch of calls to some functions. Strange. The tarball only has automake files which create a Makefile from the native auto packages. It should work fine unless the auto packages are deficient. You might want to use the fc4 srpm. It has a patch to let you use a slightly older glibc-kernheaders. The one on the people page assumes using rawhide's glibc-kernheaders. >The site mentions needing updated glibc-kernel headers, but can these even be >safely updated without hosing the system? I wouldn't permanently leave it that way. Safest thing to do is install it on the replica machine and just copy the linux/audit.h file to /usr/include/linux. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From linux at linuon.com Fri Feb 10 02:18:40 2006 From: linux at linuon.com (Junji Kanemaru) Date: Fri, 10 Feb 2006 11:18:40 +0900 Subject: shared lib problem In-Reply-To: <43EB5B8E.701@linuon.com> References: <43EADD74.2020906@linuon.com> <43EB0F4A.2070000@linuon.com> <43EB4F79.5000700@fedora.pl> <43EB5B8E.701@linuon.com> Message-ID: <43EBF800.3050601@linuon.com> It worked after reboot machine. I'm not sure what caused dlopen() error. One thing I suspect that I added a path file in /etc/ld.so.conf.d to point my plugins dir and ran ldconfig, but the cache wasn't updated properly or something like that. I had LD_CONFIG_PATH to point the plugin dir then it didn't work though. Maybe ld library related bug? Anyways, thanks for info. It seems working now. -- Junji Junji Kanemaru wrote: >>or you missed -fpic/-fPIC option when compiling your coftware > > > I missed it. After I added -fPIC the avc error has gone. > But now dlopen() fails. dlerror() says: > "No such file or directory" > > The shared libraries that my app is loading are plugins. > They are not linked with main app. they are loaded on demand > and resolved symbols on the fly. > Do I need some tweaking with them? > > -- junji > -- Junji Kanemaru Linuon Inc. Tokyo Japan From paul at city-fan.org Fri Feb 10 08:04:04 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 10 Feb 2006 08:04:04 +0000 Subject: Need help with moving the data directory of Postgresql In-Reply-To: <6168d00f0602091110u5aabce7ald7e533850cb3f917@mail.gmail.com> References: <6168d00f0602091110u5aabce7ald7e533850cb3f917@mail.gmail.com> Message-ID: <1139558644.14408.3.camel@laurel.intra.city-fan.org> On Thu, 2006-02-09 at 20:10 +0100, Markus Lindholm wrote: > Hi > > I have a FC4 box (all updates applied) on which I have a Postgresql > server (standard fedora rpms) and I'm running targeted selinux policy. > The problem is that I cannot move the data directory away > from /var/lib/pgsql/data with out turning selinux off. > > Is there any HOWTOs out there that would be helpful? > > I've tried using chcon so that the permission would be identical > between the new and the old > > [root at zeus ~]# ls -ldZ /var/lib/pgsql/data/ > drwx------ postgres postgres > system_u:object_r:postgresql_db_t /var/lib/pgsql/data/ > [root at zeus ~]# ls -lZd /mnt/raid/db/pgsql/data/ > drwx------ postgres postgres > system_u:object_r:postgresql_db_t /mnt/raid/db/pgsql/data/ > > But I still get permission denied when I try to start postgresql !! If > I mark the "Disable SELinux protection for Postgresql daemon" in the > SELinux GUI, then it starts up fine. > But what would be the correct way to handle this? Why are you moving the data directory in the first place? If it's for space reasons, an alternative approach might be simply to mount your target partition on /var/lib/pgsql/data; if you're not using an entire partition, you could use a bind mount: # mount --bind /mnt/raid/db/pgsql/data /var/lib/pgsql/data Paul. From ejtr at layer3.co.uk Fri Feb 10 18:42:19 2006 From: ejtr at layer3.co.uk (Ted Rule) Date: Fri, 10 Feb 2006 18:42:19 +0000 Subject: Nautilus Naughtiness Message-ID: <1139596940.13795.16.camel@topaz.bugfinder.co.uk> I've been having several problems recently with Nautilus and Gnome. This started ever since I adjusted my Gnome settings to save session and restore on login; I was simply too lazy to manually launch Firefox and Evolution on login. Consequently, on login, I potentially had multiple copies of Nautilus starting up, depending on how I'd left the desktop at logout. ( That's multiple windows, which Gnome collapses onto a single process, but I was seeing multiple processes under the fault conditions ). Invariably, at least one of them crashed. This became unworkable recently when I found I could make entire directories disappear from Nautilus, even though they really still existed. I drilled to a given "dangerous" directory's parent within /home, then attempted to drill one step further, only to find that the child directory started to display, and then Nautilus completely crashed. If I tried opening the directory in a new window, the child window crashed, and the parent window removed the directory from its top level listing. It seemed that the "vulnerable" directories were those which had been recently modified. Experimenting further, this seems to relate to "gam_server", as numerous denial messages appear in SELinux logs referencing this process. "gam_server" is part of gamin, as in: $ rpm -qf --queryformat="%{name}: %{summary}\n" /usr/libexec/gam_server gamin: Library providing the FAM File Alteration Monitor API The SELinux avc's only related to gam_server running under the "user_gnome_vfs_t" domain. Based on what I've seen so far, my suspicion is that the user_gnome_vfs_t domain needs read access to every directory which user_t has access to, and that if user_t can get to a directory, but user_gnome_vfs_t can't, the overall Nautilus system gets very very confused for some reason. For the present, I've added some extras to my local SELinux policy which cover most directories which Nautilus is likely to want to see, and this DOES appear to stop Nautilus crashing on login for the first time in several months. I don't think this is the complete solution, though. I suspect the proper solution is for Nautilus itself to gracefully recover from a permission denial in either the user_t OR the user_gnome_vfs_t components; or perhaps just simply abandon the user_gnome_vfs_t domain itself? Bring back CLI, all is forgiven. Extra SELinux policy: ..... # Another attempt to stop Nautilus crashing oddly.... seems to be related to the gam_server process... allow user_gnome_vfs_t { user_home_dir_t user_home_t user_fonts_t user_mozilla_home_t }:dir { search getattr read }; allow user_gnome_vfs_t { user_spamassassin_home_t user_evolution_home_t user_home_ssh_t user_gconfd_home_t }:dir { search getattr read }; allow user_gnome_vfs_t { mnt_t removable_t bin_t sbin_t var_t }:dir { search getattr read }; allow user_gnome_vfs_t { user_home_t user_untrusted_content_t user_xauth_home_t user_tmp_t }:file { getattr }; allow user_gnome_vfs_t { user_home_t }:lnk_file { read }; ..... Pertinent RPM Versions: $ rpm -q selinux-policy-strict-sources selinux-policy-strict-sources-1.27.1-2.16 $ rpm -qf /usr/bin/nautilus nautilus-2.10.0-4 $ rpm -q gamin gamin-0.1.1-3.FC4 $ rpm -qf /usr/libexec/gnome-vfs-daemon gnome-vfs2-2.10.0-5 $ rpm -qf /usr/libexec/gam_server gamin-0.1.1-3.FC4 $ -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From selinux at gmail.com Sat Feb 11 04:41:13 2006 From: selinux at gmail.com (Tom London) Date: Fri, 10 Feb 2006 20:41:13 -0800 Subject: NeworkManager..... Message-ID: <4c4ba1530602102041x43ba846ft4a79abc514176423@mail.gmail.com> Running today's rawhide: Looks like NetworkManger is having problems wpa_ctrl and /var/run/wpa_supplicant-global: ---- type=PATH msg=audit(02/10/2006 20:05:28.832:15) : item=0 flags=follow inode=2777642 dev=fd:00 mode=socket,755 ouid=root ogid=root rdev=00:00 type=SOCKETCALL msg=audit(02/10/2006 20:05:28.832:15) : nargs=3 a0=12 a1=95ee772 a2=6e type=SOCKADDR msg=audit(02/10/2006 20:05:28.832:15) : saddr=local /var/run/wpa_supplicant-global type=AVC_PATH msg=audit(02/10/2006 20:05:28.832:15) : path=/var/run/wpa_supplicant-global type=SYSCALL msg=audit(02/10/2006 20:05:28.832:15) : arch=i386 syscall=socketcall(connect) success=no exit=-13(Permission denied) a0=3 a1=b759c220 a2=0 a3=0 items=1 pid=2457 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(02/10/2006 20:05:28.832:15) : avc: denied { sendto } for pid=2457 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=PATH msg=audit(02/10/2006 20:06:19.019:23) : item=0 flags=follow inode=2777642 dev=fd:00 mode=socket,755 ouid=root ogid=root rdev=00:00 type=SOCKETCALL msg=audit(02/10/2006 20:06:19.019:23) : nargs=3 a0=12 a1=95eecca a2=6e type=SOCKADDR msg=audit(02/10/2006 20:06:19.019:23) : saddr=local /var/run/wpa_supplicant-global type=AVC_PATH msg=audit(02/10/2006 20:06:19.019:23) : path=/var/run/wpa_supplicant-global type=SYSCALL msg=audit(02/10/2006 20:06:19.019:23) : arch=i386 syscall=socketcall(connect) success=yes exit=0 a0=3 a1=b759c220 a2=2 a3=0 items=1 pid=2457 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(02/10/2006 20:06:19.019:23) : avc: denied { sendto } for pid=2457 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=PATH msg=audit(02/10/2006 20:31:01.616:36) : item=0 flags=follow inode=3626597 dev=fd:00 mode=socket,755 ouid=root ogid=root rdev=00:00 type=SOCKETCALL msg=audit(02/10/2006 20:31:01.616:36) : nargs=3 a0=7 a1=bfe73ff4 a2=0 type=SOCKADDR msg=audit(02/10/2006 20:31:01.616:36) : saddr=local /var/run/NetworkManager/wpa_ctrl_2448-3 type=SYSCALL msg=audit(02/10/2006 20:31:01.616:36) : arch=i386 syscall=socketcall(sendmsg) success=yes exit=46 a0=10 a1=bfe73fd0 a2=0 a3=9219180 items=1 pid=2908 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(02/10/2006 20:31:01.616:36) : avc: denied { write } for pid=2908 comm=wpa_supplicant name=wpa_ctrl_2448-3 dev=dm-0 ino=3626597 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file ---- type=PATH msg=audit(02/10/2006 20:31:01.632:37) : item=0 name=/var/run/NetworkManager/wpa_ctrl_2448-3 flags=parent inode=3628150 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(02/10/2006 20:31:01.632:37) : cwd=/ type=SYSCALL msg=audit(02/10/2006 20:31:01.632:37) : arch=i386 syscall=unlink success=yes exit=0 a0=95eec5e a1=0 a2=95eec58 a3=95ec128 items=1 pid=2448 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(02/10/2006 20:31:01.632:37) : avc: denied { unlink } for pid=2448 comm=NetworkManager name=wpa_ctrl_2448-3 dev=dm-0 ino=3626597 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file -- Tom London From markus.lindholm at gmail.com Sat Feb 11 09:03:54 2006 From: markus.lindholm at gmail.com (Markus Lindholm) Date: Sat, 11 Feb 2006 10:03:54 +0100 Subject: Need help with moving the data directory of Postgresql In-Reply-To: <1139558644.14408.3.camel@laurel.intra.city-fan.org> References: <6168d00f0602091110u5aabce7ald7e533850cb3f917@mail.gmail.com> <1139558644.14408.3.camel@laurel.intra.city-fan.org> Message-ID: <6168d00f0602110103p3449e85cl1681d0f102bae6c0@mail.gmail.com> Hi Used the 'mount --bind', worked well for me. Thanks. But I was wondering why it is not possible to configure Selinux to have the Postgresql data directory under /mnt? /markus On 2/10/06, Paul Howarth wrote: > > On Thu, 2006-02-09 at 20:10 +0100, Markus Lindholm wrote: > > Hi > > > > I have a FC4 box (all updates applied) on which I have a Postgresql > > server (standard fedora rpms) and I'm running targeted selinux policy. > > The problem is that I cannot move the data directory away > > from /var/lib/pgsql/data with out turning selinux off. > > > > Is there any HOWTOs out there that would be helpful? > > > > I've tried using chcon so that the permission would be identical > > between the new and the old > > > > [root at zeus ~]# ls -ldZ /var/lib/pgsql/data/ > > drwx------ postgres postgres > > system_u:object_r:postgresql_db_t /var/lib/pgsql/data/ > > [root at zeus ~]# ls -lZd /mnt/raid/db/pgsql/data/ > > drwx------ postgres postgres > > system_u:object_r:postgresql_db_t /mnt/raid/db/pgsql/data/ > > > > But I still get permission denied when I try to start postgresql !! If > > I mark the "Disable SELinux protection for Postgresql daemon" in the > > SELinux GUI, then it starts up fine. > > But what would be the correct way to handle this? > > Why are you moving the data directory in the first place? > > If it's for space reasons, an alternative approach might be simply to > mount your target partition on /var/lib/pgsql/data; if you're not using > an entire partition, you could use a bind mount: > > # mount --bind /mnt/raid/db/pgsql/data /var/lib/pgsql/data > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell at coker.com.au Sun Feb 12 06:50:45 2006 From: russell at coker.com.au (Russell Coker) Date: Sun, 12 Feb 2006 17:50:45 +1100 Subject: An interesting restorecon mislabel from selinux-policy-strict... In-Reply-To: <200602031846.k13Ikv0f009807@turing-police.cc.vt.edu> References: <200602031846.k13Ikv0f009807@turing-police.cc.vt.edu> Message-ID: <200602121750.52798.russell@coker.com.au> On Saturday 04 February 2006 05:46, Valdis.Kletnieks at vt.edu wrote: > /usr/src(/.*)? system_u:object_r:src_t:s0 > /usr(/.*)?/lib(64)?(/.*)? system_u:object_r:lib_t:s0 > > Guess what just happened to all the files under > /usr/src/linux-2.6.16-foo/lib/ The most specific entries now have the highest priority (IE they come last in the list). The solution is to add the following to the file_contexts: /usr/src/(.+/)?lib(64)?(/.*)? system_u:object_r:lib_t:s0 -- 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 Valdis.Kletnieks at vt.edu Sun Feb 12 15:58:35 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 12 Feb 2006 10:58:35 -0500 Subject: An interesting restorecon mislabel from selinux-policy-strict... In-Reply-To: Your message of "Sun, 12 Feb 2006 17:50:45 +1100." <200602121750.52798.russell@coker.com.au> References: <200602031846.k13Ikv0f009807@turing-police.cc.vt.edu> <200602121750.52798.russell@coker.com.au> Message-ID: <200602121558.k1CFwZ4q017711@turing-police.cc.vt.edu> On Sun, 12 Feb 2006 17:50:45 +1100, Russell Coker said: > On Saturday 04 February 2006 05:46, Valdis.Kletnieks at vt.edu wrote: > > /usr/src(/.*)? system_u:object_r:src_t:s0 > > /usr(/.*)?/lib(64)?(/.*)? system_u:object_r:lib_t:s0 > > > > Guess what just happened to all the files under > > /usr/src/linux-2.6.16-foo/lib/ > > The most specific entries now have the highest priority (IE they come last in > the list). > > The solution is to add the following to the file_contexts: > /usr/src/(.+/)?lib(64)?(/.*)? system_u:object_r:lib_t:s0 Won't this regexp relabel /usr/src/linux-2.6.16/lib to lib_t rather than src_t, which is the exact same problem? Or did you mean to have src_t in that? -------------- 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 Sun Feb 12 22:25:27 2006 From: russell at coker.com.au (Russell Coker) Date: Mon, 13 Feb 2006 09:25:27 +1100 Subject: An interesting restorecon mislabel from selinux-policy-strict... In-Reply-To: <200602121558.k1CFwZ4q017711@turing-police.cc.vt.edu> References: <200602031846.k13Ikv0f009807@turing-police.cc.vt.edu> <200602121750.52798.russell@coker.com.au> <200602121558.k1CFwZ4q017711@turing-police.cc.vt.edu> Message-ID: <200602130925.34762.russell@coker.com.au> On Monday 13 February 2006 02:58, Valdis.Kletnieks at vt.edu wrote: > On Sun, 12 Feb 2006 17:50:45 +1100, Russell Coker said: > > On Saturday 04 February 2006 05:46, Valdis.Kletnieks at vt.edu wrote: > > > /usr/src(/.*)? system_u:object_r:src_t:s0 > > > /usr(/.*)?/lib(64)?(/.*)? > > > system_u:object_r:lib_t:s0 > > > > > > Guess what just happened to all the files under > > > /usr/src/linux-2.6.16-foo/lib/ > > > > The most specific entries now have the highest priority (IE they come > > last in the list). > > > > The solution is to add the following to the file_contexts: > > /usr/src/(.+/)?lib(64)?(/.*)? > > system_u:object_r:lib_t:s0 > > Won't this regexp relabel /usr/src/linux-2.6.16/lib to lib_t rather than > src_t, Sorry, I thought that's what you wanted! > which is the exact same problem? Or did you mean to have src_t in > that? Yes, src_t if that's what you want. But maybe the /usr(/.*) regex needs to be replaced by several less general regexes. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From fedora at synersoft.be Mon Feb 13 04:35:17 2006 From: fedora at synersoft.be (fedora at synersoft.be) Date: Mon, 13 Feb 2006 05:35:17 +0100 Subject: postfix AVCs In-Reply-To: <20060103023054.64D50C78C6@p1> References: <20060103023054.64D50C78C6@p1> Message-ID: <20060213043519.45FE4C78C6@p1> Hello All, Using targeted policies 1.27.1-2.18 with postfix-2.2.2-2 on FC4. I receive lots of AVCs related to postfix (here is one regarding postdrop, but I have also 'sendmail.postfix', 'cleanup' and 'spamc' related AVCs) : type=AVC msg=audit(1139803214.270:14817): avc: denied { getattr } for pid=14521 comm="postdrop" name="pickup" dev=hda2 ino=6193158 scontext=root:system_r:postfix_pipe_t tcontext=system_u:object_r:postfix_public_t tclass=fifo_file type=SYSCALL msg=audit(1139803214.270:14817): arch=c000003e syscall=4 success=yes exit=0 a0=62cf28 a1=7fffffb60270 a2=7fffffb60270 a3=2aaaaaaab000 items=1 pid=14521 auid=500 uid=99 gid=99 euid=99 suid=99 fsuid=99 egid=90 sgid=90 fsgid=90 comm="postdrop" exe="/usr/sbin/postdrop" type=AVC_PATH msg=audit(1139803214.270:14817): path="/var/spool/postfix/public/pickup" type=CWD msg=audit(1139803214.270:14817): cwd="/var/spool/postfix" type=PATH msg=audit(1139803214.270:14817): item=0 name="public/pickup" flags=1 inode=6193158 dev=03:02 mode=010622 ouid=89 ogid=89 rdev=00:00 type=AVC msg=audit(1139803214.270:14818): avc: denied { write } for pid=14521 comm="postdrop" name="pickup" dev=hda2 ino=6193158 scontext=root:system_r:postfix_pipe_t tcontext=system_u:object_r:postfix_public_t tclass=fifo_file type=SYSCALL msg=audit(1139803214.270:14818): arch=c000003e syscall=2 success=yes exit=4 a0=62cf28 a1=801 a2=0 a3=2aaaaaaab000 items=1 pid=14521 auid=500 uid=99 gid=99 euid=99 suid=99 fsuid=99 egid=90 sgid=90 fsgid=90 comm="postdrop" exe="/usr/sbin/postdrop" type=CWD msg=audit(1139803214.270:14818): cwd="/var/spool/postfix" type=PATH msg=audit(1139803214.270:14818): item=0 name="public/pickup" flags=101 inode=6193158 dev=03:02 mode=010622 ouid=89 ogid=89 rdev=00:00 Any explanation ? If a known bug, could someone post a working postfix.fc/postfix.te set ? TIA From paul at city-fan.org Mon Feb 13 10:32:35 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 13 Feb 2006 10:32:35 +0000 Subject: Need help with moving the data directory of Postgresql In-Reply-To: <6168d00f0602110103p3449e85cl1681d0f102bae6c0@mail.gmail.com> References: <6168d00f0602091110u5aabce7ald7e533850cb3f917@mail.gmail.com> <1139558644.14408.3.camel@laurel.intra.city-fan.org> <6168d00f0602110103p3449e85cl1681d0f102bae6c0@mail.gmail.com> Message-ID: <43F06043.4050701@city-fan.org> Markus Lindholm wrote: > Used the 'mount --bind', worked well for me. Thanks. > > But I was wondering why it is not possible to configure Selinux to have > the Postgresql data directory under /mnt? You'd probably need to add additional policy to allow whatever needs to be able to access /var/lib/pgsql/data the ability to search /mnt as well. Paul. From craigwhite at azapple.com Tue Feb 14 08:47:50 2006 From: craigwhite at azapple.com (Craig White) Date: Tue, 14 Feb 2006 01:47:50 -0700 Subject: dispatch.fcgi aka fastcgi Message-ID: <1139906870.27212.99.camel@lin-workstation.azapple.com> trying to work with ruby on rails and apache w/ fastcgi and implementing fastcgi has left me with a real problem with all sorts of things...I'm thinking that it just might be best to give fastcgi a get out of jail free card (how do I do that?) This was only a click or two...there's no telling how many I can get by trying to use the thing (which of course seems pointless since it is denying me access to things like my css files so it looks like hell too... Feb 14 01:37:19 srv2 kernel: audit(1139906239.590:47): avc: denied { search } for pid=28974 comm="dispatch.fcgi" name="ruby-db" dev=dm-1 ino=1212642 scontext=root:system_r:htt pd_sys_script_t tcontext=user_u:object_r:user_home_t tclass=dir Feb 14 01:37:19 srv2 kernel: audit(1139906239.591:48): avc: denied { read } for pid=28974 comm="dispatch.fcgi" name="environment.rb" dev=dm-1 ino=1212686 scontext=root:system_ r:httpd_sys_script_t tcontext=user_u:object_r:user_home_t tclass=file Feb 14 01:37:19 srv2 kernel: audit(1139906239.591:49): avc: denied { getattr } for pid=28974 comm="dispatch.fcgi" name="environment.rb" dev=dm-1 ino=1212686 scontext=root:syst em_r:httpd_sys_script_t tcontext=user_u:object_r:user_home_t tclass=file Feb 14 01:37:21 srv2 kernel: audit(1139906241.708:50): avc: denied { getattr } for pid=28974 comm="dispatch.fcgi" name="models" dev=dm-1 ino=1212648 scontext=root:system_r:htt pd_sys_script_t tcontext=user_u:object_r:user_home_t tclass=dir Feb 14 01:37:21 srv2 kernel: audit(1139906241.709:51): avc: denied { read } for pid=28974 comm="dispatch.fcgi" name="models" dev=dm-1 ino=1212648 scontext=root:system_r:httpd_ sys_script_t tcontext=user_u:object_r:user_home_t tclass=dir Feb 14 01:37:21 srv2 kernel: audit(1139906241.727:52): avc: denied { append } for pid=28974 comm="dispatch.fcgi" name="production.log" dev=dm-1 ino=1212718 scontext=root:syste m_r:httpd_sys_script_t tcontext=user_u:object_r:user_home_t tclass=file Feb 14 01:37:21 srv2 kernel: audit(1139906241.781:53): avc: denied { getattr } for pid=28974 comm="dispatch.fcgi" name="fastcgi.crash.log" dev=dm-1 ino=1215942 scontext=root:s ystem_r:httpd_sys_script_t tcontext=root:object_r:user_home_t tclass=file Feb 14 01:37:21 srv2 kernel: audit(1139906241.781:54): avc: denied { append } for pid=28974 comm="dispatch.fcgi" name="fastcgi.crash.log" dev=dm-1 ino=1215942 scontext=root:sy stem_r:httpd_sys_script_t tcontext=root:object_r:user_home_t tclass=file Feb 14 01:37:21 srv2 kernel: audit(1139906241.784:55): avc: denied { getattr } for pid=28974 comm="dispatch.fcgi" name="258e9c185bb365445884d61bf2121a01" scontext=root:system_ r:httpd_sys_script_t tcontext=root:system_r:httpd_t tclass=unix_stream_socket Feb 14 01:37:21 srv2 kernel: audit(1139906241.784:56): avc: denied { accept } for pid=28974 comm="dispatch.fcgi" name="258e9c185bb365445884d61bf2121a01" scontext=root:system_r :httpd_sys_script_t tcontext=root:system_r:httpd_t tclass=unix_stream_socket Feb 14 01:37:22 srv2 kernel: audit(1139906242.315:57): avc: denied { shutdown } for pid=28974 comm="dispatch.fcgi" name="258e9c185bb365445884d61bf2121a01" scontext=root:system _r:httpd_sys_script_t tcontext=root:system_r:httpd_t tclass=unix_stream_socket From erik.sjolund at gmail.com Tue Feb 14 13:10:17 2006 From: erik.sjolund at gmail.com (=?ISO-8859-1?Q?Erik_Sj=F6lund?=) Date: Tue, 14 Feb 2006 14:10:17 +0100 Subject: risk of losing httpd_user_script_exec_t labels? Message-ID: If I inactivate httpd_unified and start using httpd_user_script_exec_t and httpd_user_script_rw_t in /home/erik/public_html, will those labels get lost (i.e reverted to httpd_user_content_t ) if I run "/sbin/fixfiles relabel"? What I'm more concerned of is if a "yum update selinux-policy-targeted" could force a relabeling and therefore loss of httpd_user_script_rw_t labels? A quick test shows that /sbin/restorecon converts httpd_user_script_rw_t to httpd_user_content_t. Though, I haven't tried "sbin/fixfiles relabel" yet. [erik at www ~]$ cd ~/public_html [erik at www public_html]$ chcon user_u:object_r:httpd_user_script_exec_t script.cgi [erik at www public_html]$ ls -lZ script.cgi -rwxr-xr-x erik others user_u:object_r:httpd_user_script_exec_t script.cgi [erik at www public_html]$ /sbin/restorecon script.cgi [erik at www public_html]$ ls -lZ script.cgi -rwxr-xr-x erik others system_u:object_r:httpd_user_content_t script.cgi [erik at www public_html]$ /usr/sbin/getsebool -a | grep unifi httpd_unified --> inactive cheers, Erik Sj?lund From fedora at synersoft.be Tue Feb 14 15:00:04 2006 From: fedora at synersoft.be (fedora at synersoft.be) Date: Tue, 14 Feb 2006 16:00:04 +0100 Subject: postfix AVCs Message-ID: <20060214150005.01691C78C6@p1> Hello All, Using targeted policies 1.27.1-2.18 with postfix-2.2.2-2 on FC4. I receive lots of AVCs related to postfix (here is one regarding postdrop, but I have also 'sendmail.postfix', 'cleanup' and 'spamc' related AVCs) : type=AVC msg=audit(1139803214.270:14817): avc: ?denied ?{ getattr } for ? pid=14521 comm="postdrop" name="pickup" dev=hda2 ino=6193158 scontext=root:system_r:postfix_pipe_t tcontext=system_u:object_r:postfix_public_t tclass=fifo_file type=SYSCALL msg=audit(1139803214.270:14817): arch=c000003e syscall=4 success=yes exit=0 a0=62cf28 a1=7fffffb60270 a2=7fffffb60270 a3=2aaaaaaab000 items=1 pid=14521 auid=500 uid=99 gid=99 euid=99 suid=99 fsuid=99 egid=90 sgid=90 fsgid=90 comm="postdrop" exe="/usr/sbin/postdrop" type=AVC_PATH msg=audit(1139803214.270:14817): ? path="/var/spool/postfix/public/pickup" type=CWD msg=audit(1139803214.270:14817): ?cwd="/var/spool/postfix" type=PATH msg=audit(1139803214.270:14817): item=0 name="public/pickup" flags=1 ? inode=6193158 dev=03:02 mode=010622 ouid=89 ogid=89 rdev=00:00 type=AVC msg=audit(1139803214.270:14818): avc: ?denied ?{ write } for ? pid=14521 comm="postdrop" name="pickup" dev=hda2 ino=6193158 scontext=root:system_r:postfix_pipe_t tcontext=system_u:object_r:postfix_public_t tclass=fifo_file type=SYSCALL msg=audit(1139803214.270:14818): arch=c000003e syscall=2 success=yes exit=4 a0=62cf28 a1=801 a2=0 a3=2aaaaaaab000 items=1 pid=14521 auid=500 uid=99 gid=99 euid=99 suid=99 fsuid=99 egid=90 sgid=90 fsgid=90 comm="postdrop" exe="/usr/sbin/postdrop" type=CWD msg=audit(1139803214.270:14818): ?cwd="/var/spool/postfix" type=PATH msg=audit(1139803214.270:14818): item=0 name="public/pickup" flags=101 ?inode=6193158 dev=03:02 mode=010622 ouid=89 ogid=89 rdev=00:00 Any explanation ? If a known bug, could someone post a working postfix.fc/postfix.te set ? TIA ====================== PS:sorry for the double posting. the first was erroneously 'in-reply-to' another message. it would be a pity that someone miss my interesting message because of threads filtering ;-) From dravet at hotmail.com Tue Feb 14 15:23:51 2006 From: dravet at hotmail.com (Jason Dravet) Date: Tue, 14 Feb 2006 09:23:51 -0600 Subject: todays avc messages Message-ID: Here are some avc messages from todays rawhide. I have tried a relabel and I still get these and more avcs in my audit.log. Hal does not work because of the last entry. Thanks, Jason time->Tue Feb 14 08:05:00 2006 type=PATH msg=audit(1139925900.906:54): item=1 flags=101 inode=393231 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1139925900.906:54): item=0 name="/sbin/auditctl" flags=101 inode=655430 dev=fd:00 mode=0100750 ouid=0 ogid=0 rdev=00:00 type=CWD msg=audit(1139925900.906:54): cwd="/" type=AVC_PATH msg=audit(1139925900.906:54): path="/ptmx" type=SYSCALL msg=audit(1139925900.906:54): arch=40000003 syscall=11 success=yes exit=0 a0=90d5f80 a1=90d5f18 a2=90dacd8 a3=90d5d88 items=2 pid=1683 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="auditctl" exe="/sbin/auditctl" type=AVC msg=audit(1139925900.906:54): avc: denied { use } for pid=1683 comm="auditctl" name="ptmx" dev=tmpfs ino=641 scontext=system_u:system_r:auditctl_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd ---- time->Tue Feb 14 08:05:01 2006 type=PATH msg=audit(1139925901.154:56): item=1 flags=101 inode=393231 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1139925901.154:56): item=0 name="/sbin/syslogd" flags=101 inode=655490 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=CWD msg=audit(1139925901.154:56): cwd="/" type=AVC_PATH msg=audit(1139925901.154:56): path="/ptmx" type=SYSCALL msg=audit(1139925901.154:56): arch=40000003 syscall=11 success=yes exit=0 a0=9e89ad0 a1=9e8a0c0 a2=9e89fc8 a3=9e89a40 items=2 pid=1692 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="syslogd" exe="/sbin/syslogd" type=AVC msg=audit(1139925901.154:56): avc: denied { use } for pid=1692 comm="syslogd" name="ptmx" dev=tmpfs ino=641 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd ---- time->Tue Feb 14 08:05:01 2006 type=PATH msg=audit(1139925901.366:57): item=1 flags=101 inode=393231 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1139925901.366:57): item=0 name="/sbin/klogd" flags=101 inode=655480 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=CWD msg=audit(1139925901.366:57): cwd="/" type=AVC_PATH msg=audit(1139925901.366:57): path="/ptmx" type=SYSCALL msg=audit(1139925901.366:57): arch=40000003 syscall=11 success=yes exit=0 a0=904bb10 a1=904c060 a2=904bf70 a3=904b9c8 items=2 pid=1695 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="klogd" exe="/sbin/klogd" type=AVC msg=audit(1139925901.366:57): avc: denied { use } for pid=1695 comm="klogd" name="ptmx" dev=tmpfs ino=641 scontext=system_u:system_r:klogd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd ---- time->Tue Feb 14 09:18:05 2006 type=SYSCALL msg=audit(1139930285.404:256): arch=40000003 syscall=206 success=no exit=-1 a0=1 a1=9ec2338 a2=351ff4 a3=1 items=0 pid=3426 auid=0 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(1139930285.404:256): avc: denied { setgid } for pid=3426 comm="hald" capability=6 scontext=root:system_r:hald_t:s0 tcontext=root:system_r:hald_t:s0 tclass=capability From dwalsh at redhat.com Tue Feb 14 17:46:12 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 14 Feb 2006 12:46:12 -0500 Subject: risk of losing httpd_user_script_exec_t labels? In-Reply-To: References: Message-ID: <43F21764.8090907@redhat.com> Erik Sj?lund wrote: > If I inactivate httpd_unified and start using httpd_user_script_exec_t > and httpd_user_script_rw_t in /home/erik/public_html, will those > labels get lost (i.e reverted to httpd_user_content_t ) if I run > "/sbin/fixfiles relabel"? > > What I'm more concerned of is if a > "yum update selinux-policy-targeted" > could force a relabeling and therefore loss of httpd_user_script_rw_t labels? > > A quick test shows that /sbin/restorecon converts httpd_user_script_rw_t to > httpd_user_content_t. > Though, I haven't tried "sbin/fixfiles relabel" yet. > > [erik at www ~]$ cd ~/public_html > [erik at www public_html]$ chcon user_u:object_r:httpd_user_script_exec_t > script.cgi > [erik at www public_html]$ ls -lZ script.cgi > -rwxr-xr-x erik others user_u:object_r:httpd_user_script_exec_t script.cgi > [erik at www public_html]$ /sbin/restorecon script.cgi > [erik at www public_html]$ ls -lZ script.cgi > -rwxr-xr-x erik others system_u:object_r:httpd_user_content_t script.cgi > [erik at www public_html]$ /usr/sbin/getsebool -a | grep unifi > httpd_unified --> inactive > That looks like a bug. What OS? Policy version are you using? httpd_user_script* are supposed to be customizable types, which means that restorecon/setfiles/fixfiles leaves them alone by default. > cheers, > Erik Sj?lund > > -- > 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 Feb 14 17:47:37 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 14 Feb 2006 12:47:37 -0500 Subject: todays avc messages In-Reply-To: References: Message-ID: <43F217B9.3090506@redhat.com> Jason Dravet wrote: > Here are some avc messages from todays rawhide. I have tried a > relabel and I still get these and more avcs in my audit.log. Hal does > not work because of the last entry. > > Thanks, > Jason > > time->Tue Feb 14 08:05:00 2006 > type=PATH msg=audit(1139925900.906:54): item=1 flags=101 inode=393231 > dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 > type=PATH msg=audit(1139925900.906:54): item=0 name="/sbin/auditctl" > flags=101 inode=655430 dev=fd:00 mode=0100750 ouid=0 ogid=0 rdev=00:00 > type=CWD msg=audit(1139925900.906:54): cwd="/" > type=AVC_PATH msg=audit(1139925900.906:54): path="/ptmx" > type=SYSCALL msg=audit(1139925900.906:54): arch=40000003 syscall=11 > success=yes exit=0 a0=90d5f80 a1=90d5f18 a2=90dacd8 a3=90d5d88 items=2 > pid=1683 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 comm="auditctl" exe="/sbin/auditctl" > type=AVC msg=audit(1139925900.906:54): avc: denied { use } for > pid=1683 comm="auditctl" name="ptmx" dev=tmpfs ino=641 > scontext=system_u:system_r:auditctl_t:s0 > tcontext=system_u:system_r:kernel_t:s0 tclass=fd > ---- > time->Tue Feb 14 08:05:01 2006 > type=PATH msg=audit(1139925901.154:56): item=1 flags=101 inode=393231 > dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 > type=PATH msg=audit(1139925901.154:56): item=0 name="/sbin/syslogd" > flags=101 inode=655490 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 > type=CWD msg=audit(1139925901.154:56): cwd="/" > type=AVC_PATH msg=audit(1139925901.154:56): path="/ptmx" > type=SYSCALL msg=audit(1139925901.154:56): arch=40000003 syscall=11 > success=yes exit=0 a0=9e89ad0 a1=9e8a0c0 a2=9e89fc8 a3=9e89a40 items=2 > pid=1692 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 comm="syslogd" exe="/sbin/syslogd" > type=AVC msg=audit(1139925901.154:56): avc: denied { use } for > pid=1692 comm="syslogd" name="ptmx" dev=tmpfs ino=641 > scontext=system_u:system_r:syslogd_t:s0 > tcontext=system_u:system_r:kernel_t:s0 tclass=fd > ---- > time->Tue Feb 14 08:05:01 2006 > type=PATH msg=audit(1139925901.366:57): item=1 flags=101 inode=393231 > dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 > type=PATH msg=audit(1139925901.366:57): item=0 name="/sbin/klogd" > flags=101 inode=655480 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 > type=CWD msg=audit(1139925901.366:57): cwd="/" > type=AVC_PATH msg=audit(1139925901.366:57): path="/ptmx" > type=SYSCALL msg=audit(1139925901.366:57): arch=40000003 syscall=11 > success=yes exit=0 a0=904bb10 a1=904c060 a2=904bf70 a3=904b9c8 items=2 > pid=1695 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 comm="klogd" exe="/sbin/klogd" > type=AVC msg=audit(1139925901.366:57): avc: denied { use } for > pid=1695 comm="klogd" name="ptmx" dev=tmpfs ino=641 > scontext=system_u:system_r:klogd_t:s0 > tcontext=system_u:system_r:kernel_t:s0 tclass=fd > ---- > time->Tue Feb 14 09:18:05 2006 > type=SYSCALL msg=audit(1139930285.404:256): arch=40000003 syscall=206 > success=no exit=-1 a0=1 a1=9ec2338 a2=351ff4 a3=1 items=0 pid=3426 > auid=0 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(1139930285.404:256): avc: denied { setgid } for > pid=3426 comm="hald" capability=6 scontext=root:system_r:hald_t:s0 > tcontext=root:system_r:hald_t:s0 tclass=capability > Yes the hal one is the only important one. I have update policy on ftp://people.redhat.com/dwalsh/SELinux/Fedora to fix this. The others are being caused by a leaking file descriptor in the kernel or the initrd. A bugzilla has been filed. Dan > > -- > 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 Feb 14 17:50:47 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 14 Feb 2006 12:50:47 -0500 Subject: Need help with moving the data directory of Postgresql In-Reply-To: <6168d00f0602110103p3449e85cl1681d0f102bae6c0@mail.gmail.com> References: <6168d00f0602091110u5aabce7ald7e533850cb3f917@mail.gmail.com> <1139558644.14408.3.camel@laurel.intra.city-fan.org> <6168d00f0602110103p3449e85cl1681d0f102bae6c0@mail.gmail.com> Message-ID: <43F21877.7060606@redhat.com> Markus Lindholm wrote: > Hi > > Used the 'mount --bind', worked well for me. Thanks. > > But I was wondering why it is not possible to configure Selinux to > have the Postgresql data directory under /mnt? > > /markus > > On 2/10/06, *Paul Howarth* > wrote: > > On Thu, 2006-02-09 at 20:10 +0100, Markus Lindholm wrote: > > Hi > > > > I have a FC4 box (all updates applied) on which I have a Postgresql > > server (standard fedora rpms) and I'm running targeted selinux > policy. > > The problem is that I cannot move the data directory away > > from /var/lib/pgsql/data with out turning selinux off. > > > > Is there any HOWTOs out there that would be helpful? > > > > I've tried using chcon so that the permission would be identical > > between the new and the old > > > > [root at zeus ~]# ls -ldZ /var/lib/pgsql/data/ > > drwx------ postgres postgres > > system_u:object_r:postgresql_db_t /var/lib/pgsql/data/ > > [root at zeus ~]# ls -lZd /mnt/raid/db/pgsql/data/ > > drwx------ postgres postgres > > system_u:object_r:postgresql_db_t /mnt/raid/db/pgsql/data/ > > > > But I still get permission denied when I try to start postgresql > !! If > > I mark the "Disable SELinux protection for Postgresql daemon" in > the > > SELinux GUI, then it starts up fine. > > But what would be the correct way to handle this? > > Why are you moving the data directory in the first place? > > If it's for space reasons, an alternative approach might be simply to > mount your target partition on /var/lib/pgsql/data; if you're not > using > an entire partition, you could use a bind mount: > > # mount --bind /mnt/raid/db/pgsql/data /var/lib/pgsql/data > You could, but then other applications that are allowed to search mnt_t would be able to also, and a corrupted postgres could attack things on /mnt. The idea is to isolate applications based on least privs so storing data/files in places like /tmp or /mnt is not usually a good idea for a confined application. > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From erik.sjolund at gmail.com Wed Feb 15 13:19:29 2006 From: erik.sjolund at gmail.com (Erik =?ISO-8859-1?Q?Sj=F6lund?=) Date: Wed, 15 Feb 2006 14:19:29 +0100 Subject: /sbin/restorecon and hard links Message-ID: <1140009569.2761.34.camel@otto> [root at e /]# cat /etc/redhat-release Fedora Core release 4 (Stentz) [root at e /]# adduser erik [root at e /]# su - erik [erik at e ~]$ ln /etc/passwd . [erik at e ~]$ exit [root at e /]# ls -lZ /etc/passwd -rw-r--r-- root root system_u:object_r:etc_t /etc/passwd [root at e /]# restorecon -R /home [root at e /]# ls -lZ /etc/passwd -rw-r--r-- root root user_u:object_r:user_home_t /etc/passwd Should it be like that? /sbin/restorecon -R /home might lead to strange security contexts for files belonging to root. cheers, Erik From erik.sjolund at gmail.com Wed Feb 15 13:20:41 2006 From: erik.sjolund at gmail.com (Erik =?ISO-8859-1?Q?Sj=F6lund?=) Date: Wed, 15 Feb 2006 14:20:41 +0100 Subject: risk of losing httpd_user_script_exec_t labels? In-Reply-To: <43F21764.8090907@redhat.com> References: <43F21764.8090907@redhat.com> Message-ID: <1140009641.2761.36.camel@otto> On Tue, 2006-02-14 at 12:46 -0500, Daniel J Walsh wrote: > That looks like a bug. What OS? Policy version are you using? > httpd_user_script* are supposed to be > customizable types, which means that restorecon/setfiles/fixfiles leaves > them alone by default. Centos 4.2 and targeted policy, so sorry about the noise. I checked Fedora Core 4 and indeed it works there. cheers, Erik From sds at tycho.nsa.gov Wed Feb 15 14:01:32 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 15 Feb 2006 09:01:32 -0500 Subject: /sbin/restorecon and hard links In-Reply-To: <1140009569.2761.34.camel@otto> References: <1140009569.2761.34.camel@otto> Message-ID: <1140012092.14253.358.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-02-15 at 14:19 +0100, Erik Sj?lund wrote: > [root at e /]# cat /etc/redhat-release > Fedora Core release 4 (Stentz) > [root at e /]# adduser erik > [root at e /]# su - erik > [erik at e ~]$ ln /etc/passwd . > [erik at e ~]$ exit > [root at e /]# ls -lZ /etc/passwd > -rw-r--r-- root root system_u:object_r:etc_t /etc/passwd > [root at e /]# restorecon -R /home > [root at e /]# ls -lZ /etc/passwd > -rw-r--r-- root root user_u:object_r:user_home_t /etc/passwd > > Should it be like that? > > /sbin/restorecon -R /home > > might lead to strange security contexts for files belonging to root. Yes, running restorecon on /home by root considered harmful, particularly under targeted policy. Under strict policy, a user can't create hard links to system files (controlled by the 'link' permission), which helps avoid the problem, and restorecon and setfiles aren't allowed to follow untrustworthy symlinks by the policy. setfiles also contains code to check for multiple hard links with conflicting matches, so if you run setfiles on /, it should complain about the discrepancy, but restorecon doesn't do that and even if it did it naturally can't tell that when it is just run on /home. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Feb 15 14:09:12 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 15 Feb 2006 09:09:12 -0500 Subject: /sbin/restorecon and hard links In-Reply-To: <1140012092.14253.358.camel@moss-spartans.epoch.ncsc.mil> References: <1140009569.2761.34.camel@otto> <1140012092.14253.358.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1140012552.14253.364.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-02-15 at 09:01 -0500, Stephen Smalley wrote: > Yes, running restorecon on /home by root considered harmful, > particularly under targeted policy. Under strict policy, a user can't > create hard links to system files (controlled by the 'link' permission), > which helps avoid the problem, and restorecon and setfiles aren't > allowed to follow untrustworthy symlinks by the policy. setfiles also > contains code to check for multiple hard links with conflicting matches, > so if you run setfiles on /, it should complain about the discrepancy, > but restorecon doesn't do that and even if it did it naturally can't > tell that when it is just run on /home. Of course, using a separate partition for /home, /tmp, and other user-writable areas is a good idea anyway... -- Stephen Smalley National Security Agency From cra at WPI.EDU Wed Feb 15 14:33:26 2006 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 15 Feb 2006 09:33:26 -0500 Subject: /sbin/restorecon and hard links In-Reply-To: <1140012092.14253.358.camel@moss-spartans.epoch.ncsc.mil> References: <1140009569.2761.34.camel@otto> <1140012092.14253.358.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20060215143326.GI5657@angus.ind.WPI.EDU> On Wed, Feb 15, 2006 at 09:01:32AM -0500, Stephen Smalley wrote: > Yes, running restorecon on /home by root considered harmful, What is a safe way to run restorecon on /home? Should I su to each user and do their home directory separately from all others? From sds at tycho.nsa.gov Wed Feb 15 14:44:53 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 15 Feb 2006 09:44:53 -0500 Subject: /sbin/restorecon and hard links In-Reply-To: <20060215143326.GI5657@angus.ind.WPI.EDU> References: <1140009569.2761.34.camel@otto> <1140012092.14253.358.camel@moss-spartans.epoch.ncsc.mil> <20060215143326.GI5657@angus.ind.WPI.EDU> Message-ID: <1140014693.14253.376.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-02-15 at 09:33 -0500, Chuck Anderson wrote: > On Wed, Feb 15, 2006 at 09:01:32AM -0500, Stephen Smalley wrote: > > Yes, running restorecon on /home by root considered harmful, > > What is a safe way to run restorecon on /home? Should I su to each > user and do their home directory separately from all others? The real question is why do you need to do it? If the labels are set up properly on installation and when the user's account is first created, then you shouldn't need to do it subsequently, and the user can run restorecon themselves on their own home directory if they encounter issues. su has its own issues irrespective of SELinux; never su to an untrusted account. -- Stephen Smalley National Security Agency From cra at WPI.EDU Wed Feb 15 14:50:47 2006 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 15 Feb 2006 09:50:47 -0500 Subject: /sbin/restorecon and hard links In-Reply-To: <1140014693.14253.376.camel@moss-spartans.epoch.ncsc.mil> References: <1140009569.2761.34.camel@otto> <1140012092.14253.358.camel@moss-spartans.epoch.ncsc.mil> <20060215143326.GI5657@angus.ind.WPI.EDU> <1140014693.14253.376.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20060215145047.GJ5657@angus.ind.WPI.EDU> On Wed, Feb 15, 2006 at 09:44:53AM -0500, Stephen Smalley wrote: > On Wed, 2006-02-15 at 09:33 -0500, Chuck Anderson wrote: > > On Wed, Feb 15, 2006 at 09:01:32AM -0500, Stephen Smalley wrote: > > > Yes, running restorecon on /home by root considered harmful, > > > > What is a safe way to run restorecon on /home? Should I su to each > > user and do their home directory separately from all others? > > The real question is why do you need to do it? If the labels are set up > properly on installation and when the user's account is first created, > then you shouldn't need to do it subsequently, and the user can run > restorecon themselves on their own home directory if they encounter > issues. su has its own issues irrespective of SELinux; never su to an > untrusted account. Restores from backup. Until our backup utility supports extended attributes, we will have to use restorecon so at least the default labels are set up properly. Also, assuming we do backup extended attributes, will this problem still exist when restoring them from backup? From sds at tycho.nsa.gov Wed Feb 15 15:09:48 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 15 Feb 2006 10:09:48 -0500 Subject: /sbin/restorecon and hard links In-Reply-To: <20060215145047.GJ5657@angus.ind.WPI.EDU> References: <1140009569.2761.34.camel@otto> <1140012092.14253.358.camel@moss-spartans.epoch.ncsc.mil> <20060215143326.GI5657@angus.ind.WPI.EDU> <1140014693.14253.376.camel@moss-spartans.epoch.ncsc.mil> <20060215145047.GJ5657@angus.ind.WPI.EDU> Message-ID: <1140016188.14253.387.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-02-15 at 09:50 -0500, Chuck Anderson wrote: > Restores from backup. Until our backup utility supports extended > attributes, we will have to use restorecon so at least the default > labels are set up properly. In the file restoration case, you are re-creating files under /home, so they won't be hard links to system files, and presumably the user isn't allowed to login while you are restoring his home directory, so he can't create any links during that process. > Also, assuming we do backup extended attributes, will this problem > still exist when restoring them from backup? You won't have to run restorecon in that case, and the restore utility presumably would just set the attributes as it creates each file, so likely not. But remember that targeted policy doesn't confine users, only specific programs/daemons, so if you are using it, you aren't relying on SELinux to counter malicious users at all, so this is no different. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Feb 15 15:16:38 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 15 Feb 2006 10:16:38 -0500 Subject: /sbin/restorecon and hard links In-Reply-To: <1140016188.14253.387.camel@moss-spartans.epoch.ncsc.mil> References: <1140009569.2761.34.camel@otto> <1140012092.14253.358.camel@moss-spartans.epoch.ncsc.mil> <20060215143326.GI5657@angus.ind.WPI.EDU> <1140014693.14253.376.camel@moss-spartans.epoch.ncsc.mil> <20060215145047.GJ5657@angus.ind.WPI.EDU> <1140016188.14253.387.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1140016598.14253.392.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-02-15 at 10:09 -0500, Stephen Smalley wrote: > On Wed, 2006-02-15 at 09:50 -0500, Chuck Anderson wrote: > > Restores from backup. Until our backup utility supports extended > > attributes, we will have to use restorecon so at least the default > > labels are set up properly. > > In the file restoration case, you are re-creating files under /home, so > they won't be hard links to system files, and presumably the user isn't > allowed to login while you are restoring his home directory, so he can't > create any links during that process. > > > Also, assuming we do backup extended attributes, will this problem > > still exist when restoring them from backup? > > You won't have to run restorecon in that case, and the restore utility > presumably would just set the attributes as it creates each file, so > likely not. But remember that targeted policy doesn't confine users, > only specific programs/daemons, so if you are using it, you aren't > relying on SELinux to counter malicious users at all, so this is no > different. By the way, /etc/profile.d/selinux.* already runs restorecon by default when the user logs in on certain user files and directories to ensure that they are labeled properly. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Feb 15 15:19:08 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 15 Feb 2006 10:19:08 -0500 Subject: /sbin/restorecon and hard links In-Reply-To: <1140012092.14253.358.camel@moss-spartans.epoch.ncsc.mil> References: <1140009569.2761.34.camel@otto> <1140012092.14253.358.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1140016748.14253.395.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-02-15 at 09:01 -0500, Stephen Smalley wrote: > Yes, running restorecon on /home by root considered harmful, > particularly under targeted policy. Under strict policy, a user can't > create hard links to system files (controlled by the 'link' permission), > which helps avoid the problem, and restorecon and setfiles aren't > allowed to follow untrustworthy symlinks by the policy. setfiles also > contains code to check for multiple hard links with conflicting matches, > so if you run setfiles on /, it should complain about the discrepancy, > but restorecon doesn't do that and even if it did it naturally can't > tell that when it is just run on /home. BTW, it is important to remember here that targeted policy doesn't try to confine users (just specific programs and daemons) and that relabeling /etc/passwd or other system files doesn't give the user any greater access since he is already unconfined as far as SELinux is concerned. -- Stephen Smalley National Security Agency From jreiser at BitWagon.com Wed Feb 15 15:44:43 2006 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 15 Feb 2006 07:44:43 -0800 Subject: /sbin/restorecon and hard links In-Reply-To: <1140016748.14253.395.camel@moss-spartans.epoch.ncsc.mil> References: <1140009569.2761.34.camel@otto> <1140012092.14253.358.camel@moss-spartans.epoch.ncsc.mil> <1140016748.14253.395.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <43F34C6B.4020405@BitWagon.com> Stephen Smalley wrote: > BTW, it is important to remember here that targeted policy doesn't try > to confine users (just specific programs and daemons) and that > relabeling /etc/passwd or other system files doesn't give the user any > greater access since he is already unconfined as far as SELinux is > concerned. That's true for SELinux policy itself. However, the linux kernel _does_ confine users, independent of "external [to the kernel]" SELinux policy, as an unavoidable part of the complete selinux package. Namely, the restrictions on execmod and execmem can make life difficult for legitimate software which uses non-mainstream techniques to achieve higher performance and/or create a richer debugging environment. Even in targeted mode, SELinux has greater-than-zero operational costs for non-targeted software. -- From sds at tycho.nsa.gov Wed Feb 15 16:07:28 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 15 Feb 2006 11:07:28 -0500 Subject: /sbin/restorecon and hard links In-Reply-To: <43F34C6B.4020405@BitWagon.com> References: <1140009569.2761.34.camel@otto> <1140012092.14253.358.camel@moss-spartans.epoch.ncsc.mil> <1140016748.14253.395.camel@moss-spartans.epoch.ncsc.mil> <43F34C6B.4020405@BitWagon.com> Message-ID: <1140019648.14253.400.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-02-15 at 07:44 -0800, John Reiser wrote: > Stephen Smalley wrote: > > BTW, it is important to remember here that targeted policy doesn't try > > to confine users (just specific programs and daemons) and that > > relabeling /etc/passwd or other system files doesn't give the user any > > greater access since he is already unconfined as far as SELinux is > > concerned. > > That's true for SELinux policy itself. However, the linux kernel _does_ > confine users, independent of "external [to the kernel]" SELinux policy, > as an unavoidable part of the complete selinux package. Namely, the > restrictions on execmod and execmem can make life difficult for legitimate > software which uses non-mainstream techniques to achieve higher performance > and/or create a richer debugging environment. Even in targeted mode, > SELinux has greater-than-zero operational costs for non-targeted software. The exec* checks are a bit different in that they are primarily protecting the user from malicious activity (e.g. preventing his stack from being made executable) rather than protecting the system against a malicious user. So the original poster was worried about a user maliciously hard linking to /etc/passwd in order to trick restorecon run by root later into mislabeling the file, but that doesn't create any greater exposure than already existed since the user was already unconfined by SELinux (but still limited by Linux DAC, so regardless of the SELinux label, the user still couldn't write to /etc/passwd). Whereas under strict policy, the user would be confined, and wouldn't be allowed to hard link to /etc/passwd in the first place. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Wed Feb 15 21:31:10 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 15 Feb 2006 16:31:10 -0500 Subject: dispatch.fcgi aka fastcgi In-Reply-To: <1139906870.27212.99.camel@lin-workstation.azapple.com> References: <1139906870.27212.99.camel@lin-workstation.azapple.com> Message-ID: <43F39D9E.5080500@redhat.com> Craig White wrote: > trying to work with ruby on rails and apache w/ fastcgi and implementing > fastcgi has left me with a real problem with all sorts of things...I'm > thinking that it just might be best to give fastcgi a get out of jail > free card (how do I do that?) > > This was only a click or two...there's no telling how many I can get by > trying to use the thing (which of course seems pointless since it is > denying me access to things like my css files so it looks like hell > too... > > Feb 14 01:37:19 srv2 kernel: audit(1139906239.590:47): avc: denied > { search } for pid=28974 comm="dispatch.fcgi" name="ruby-db" dev=dm-1 > ino=1212642 scontext=root:system_r:htt > pd_sys_script_t tcontext=user_u:object_r:user_home_t tclass=dir > Feb 14 01:37:19 srv2 kernel: audit(1139906239.591:48): avc: denied > { read } for pid=28974 comm="dispatch.fcgi" name="environment.rb" > dev=dm-1 ino=1212686 scontext=root:system_ > r:httpd_sys_script_t tcontext=user_u:object_r:user_home_t tclass=file > Feb 14 01:37:19 srv2 kernel: audit(1139906239.591:49): avc: denied > { getattr } for pid=28974 comm="dispatch.fcgi" name="environment.rb" > dev=dm-1 ino=1212686 scontext=root:syst > em_r:httpd_sys_script_t tcontext=user_u:object_r:user_home_t tclass=file > Feb 14 01:37:21 srv2 kernel: audit(1139906241.708:50): avc: denied > { getattr } for pid=28974 comm="dispatch.fcgi" name="models" dev=dm-1 > ino=1212648 scontext=root:system_r:htt > pd_sys_script_t tcontext=user_u:object_r:user_home_t tclass=dir > Feb 14 01:37:21 srv2 kernel: audit(1139906241.709:51): avc: denied > { read } for pid=28974 comm="dispatch.fcgi" name="models" dev=dm-1 > ino=1212648 scontext=root:system_r:httpd_ > sys_script_t tcontext=user_u:object_r:user_home_t tclass=dir > Feb 14 01:37:21 srv2 kernel: audit(1139906241.727:52): avc: denied > { append } for pid=28974 comm="dispatch.fcgi" name="production.log" > dev=dm-1 ino=1212718 scontext=root:syste > m_r:httpd_sys_script_t tcontext=user_u:object_r:user_home_t tclass=file > Feb 14 01:37:21 srv2 kernel: audit(1139906241.781:53): avc: denied > { getattr } for pid=28974 comm="dispatch.fcgi" name="fastcgi.crash.log" > dev=dm-1 ino=1215942 scontext=root:s > ystem_r:httpd_sys_script_t tcontext=root:object_r:user_home_t > tclass=file > Feb 14 01:37:21 srv2 kernel: audit(1139906241.781:54): avc: denied > { append } for pid=28974 comm="dispatch.fcgi" name="fastcgi.crash.log" > dev=dm-1 ino=1215942 scontext=root:sy > stem_r:httpd_sys_script_t tcontext=root:object_r:user_home_t tclass=file > Feb 14 01:37:21 srv2 kernel: audit(1139906241.784:55): avc: denied > { getattr } for pid=28974 comm="dispatch.fcgi" > name="258e9c185bb365445884d61bf2121a01" scontext=root:system_ > r:httpd_sys_script_t tcontext=root:system_r:httpd_t > tclass=unix_stream_socket > Feb 14 01:37:21 srv2 kernel: audit(1139906241.784:56): avc: denied > { accept } for pid=28974 comm="dispatch.fcgi" > name="258e9c185bb365445884d61bf2121a01" scontext=root:system_r > :httpd_sys_script_t tcontext=root:system_r:httpd_t > tclass=unix_stream_socket > Feb 14 01:37:22 srv2 kernel: audit(1139906242.315:57): avc: denied > { shutdown } for pid=28974 comm="dispatch.fcgi" > name="258e9c185bb365445884d61bf2121a01" scontext=root:system > _r:httpd_sys_script_t tcontext=root:system_r:httpd_t > tclass=unix_stream_socket > > You need to label the files/directory that the cgi wants to manipulate on your homedirs as httpd_sys_script_rw_t > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From craigwhite at azapple.com Wed Feb 15 21:47:03 2006 From: craigwhite at azapple.com (Craig White) Date: Wed, 15 Feb 2006 14:47:03 -0700 Subject: dispatch.fcgi aka fastcgi In-Reply-To: <43F39D9E.5080500@redhat.com> References: <1139906870.27212.99.camel@lin-workstation.azapple.com> <43F39D9E.5080500@redhat.com> Message-ID: <1140040023.14980.43.camel@lin-workstation.azapple.com> On Wed, 2006-02-15 at 16:31 -0500, Daniel J Walsh wrote: > Craig White wrote: > > trying to work with ruby on rails and apache w/ fastcgi and implementing > > fastcgi has left me with a real problem with all sorts of things...I'm > > thinking that it just might be best to give fastcgi a get out of jail > > free card (how do I do that?) > > > > This was only a click or two...there's no telling how many I can get by > > trying to use the thing (which of course seems pointless since it is > > denying me access to things like my css files so it looks like hell > > too... > > > > Feb 14 01:37:19 srv2 kernel: audit(1139906239.590:47): avc: denied > > { search } for pid=28974 comm="dispatch.fcgi" name="ruby-db" dev=dm-1 > > ino=1212642 scontext=root:system_r:htt > > pd_sys_script_t tcontext=user_u:object_r:user_home_t tclass=dir > > Feb 14 01:37:19 srv2 kernel: audit(1139906239.591:48): avc: denied > > { read } for pid=28974 comm="dispatch.fcgi" name="environment.rb" > > dev=dm-1 ino=1212686 scontext=root:system_ > > r:httpd_sys_script_t tcontext=user_u:object_r:user_home_t tclass=file > > Feb 14 01:37:19 srv2 kernel: audit(1139906239.591:49): avc: denied > > { getattr } for pid=28974 comm="dispatch.fcgi" name="environment.rb" > > dev=dm-1 ino=1212686 scontext=root:syst > > em_r:httpd_sys_script_t tcontext=user_u:object_r:user_home_t tclass=file > > Feb 14 01:37:21 srv2 kernel: audit(1139906241.708:50): avc: denied > > { getattr } for pid=28974 comm="dispatch.fcgi" name="models" dev=dm-1 > > ino=1212648 scontext=root:system_r:htt > > pd_sys_script_t tcontext=user_u:object_r:user_home_t tclass=dir > > Feb 14 01:37:21 srv2 kernel: audit(1139906241.709:51): avc: denied > > { read } for pid=28974 comm="dispatch.fcgi" name="models" dev=dm-1 > > ino=1212648 scontext=root:system_r:httpd_ > > sys_script_t tcontext=user_u:object_r:user_home_t tclass=dir > > Feb 14 01:37:21 srv2 kernel: audit(1139906241.727:52): avc: denied > > { append } for pid=28974 comm="dispatch.fcgi" name="production.log" > > dev=dm-1 ino=1212718 scontext=root:syste > > m_r:httpd_sys_script_t tcontext=user_u:object_r:user_home_t tclass=file > > Feb 14 01:37:21 srv2 kernel: audit(1139906241.781:53): avc: denied > > { getattr } for pid=28974 comm="dispatch.fcgi" name="fastcgi.crash.log" > > dev=dm-1 ino=1215942 scontext=root:s > > ystem_r:httpd_sys_script_t tcontext=root:object_r:user_home_t > > tclass=file > > Feb 14 01:37:21 srv2 kernel: audit(1139906241.781:54): avc: denied > > { append } for pid=28974 comm="dispatch.fcgi" name="fastcgi.crash.log" > > dev=dm-1 ino=1215942 scontext=root:sy > > stem_r:httpd_sys_script_t tcontext=root:object_r:user_home_t tclass=file > > Feb 14 01:37:21 srv2 kernel: audit(1139906241.784:55): avc: denied > > { getattr } for pid=28974 comm="dispatch.fcgi" > > name="258e9c185bb365445884d61bf2121a01" scontext=root:system_ > > r:httpd_sys_script_t tcontext=root:system_r:httpd_t > > tclass=unix_stream_socket > > Feb 14 01:37:21 srv2 kernel: audit(1139906241.784:56): avc: denied > > { accept } for pid=28974 comm="dispatch.fcgi" > > name="258e9c185bb365445884d61bf2121a01" scontext=root:system_r > > :httpd_sys_script_t tcontext=root:system_r:httpd_t > > tclass=unix_stream_socket > > Feb 14 01:37:22 srv2 kernel: audit(1139906242.315:57): avc: denied > > { shutdown } for pid=28974 comm="dispatch.fcgi" > > name="258e9c185bb365445884d61bf2121a01" scontext=root:system > > _r:httpd_sys_script_t tcontext=root:system_r:httpd_t > > tclass=unix_stream_socket > > > > > You need to label the files/directory that the cgi wants to manipulate > on your homedirs as httpd_sys_script_rw_t ---- yeah thanks - I actually solved it with 'setsebool -P httpd_enable_homedirs 0' and chcon httpd_sys_script_rw_t /home/craig... I think that's what I did...I'm in memory mode but it fixed it. I tried to post a nevermind to the list and ended up sending it to myself and since it was quite some time before I realized what I had done and nobody responded...I just let it go. Sorry for the noise. Thanks Craig From nicolas.mailhot at laposte.net Thu Feb 16 07:36:25 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 16 Feb 2006 08:36:25 +0100 Subject: More FC5 AVCs Message-ID: <1140075385.2809.6.camel@rousalka.dyndns.org> Hi, I've attached a new AVC report at : https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=124742 to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172088 This is generated on a clean up-to-date rawhide system. This late in the game you'd expect everything to be mostly fixed (it did look like this a few days ago) but unfortunately it isn't. A lot of long-known problems rear their ugly heads again. It's almost as if the selinux policies where OK but the system labelling was degenerating over time. The log was generated after 5 min of uptime max. I expect I haven't hit yet the rest of the problems (and I won't - I need some of the blocked apps so it's setenforce 0 from now on) 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 nicolas.mailhot at laposte.net Thu Feb 16 07:43:27 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 16 Feb 2006 08:43:27 +0100 Subject: More FC5 AVCs In-Reply-To: <1140075385.2809.6.camel@rousalka.dyndns.org> References: <1140075385.2809.6.camel@rousalka.dyndns.org> Message-ID: <1140075808.2809.7.camel@rousalka.dyndns.org> Le jeudi 16 f?vrier 2006 ? 08:36 +0100, Nicolas Mailhot a ?crit : > I've attached a new AVC report at : > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=124742 make it https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=124743 instead, seems I attached some old file last time 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 dwalsh at redhat.com Thu Feb 16 15:32:31 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 16 Feb 2006 10:32:31 -0500 Subject: More FC5 AVCs In-Reply-To: <1140075808.2809.7.camel@rousalka.dyndns.org> References: <1140075385.2809.6.camel@rousalka.dyndns.org> <1140075808.2809.7.camel@rousalka.dyndns.org> Message-ID: <43F49B0F.70605@redhat.com> Nicolas Mailhot wrote: > Le jeudi 16 f?vrier 2006 ? 08:36 +0100, Nicolas Mailhot a ?crit : > > >> I've attached a new AVC report at : >> https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=124742 >> > > make it > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=124743 > > instead, seems I attached some old file last time > > Regards, > > The large number of AVCs was caused by people rushing to put last minute fixes before the FC5 Test 3 Freeze. We updated policy to fix them and fixed some kernel problems. We are investigating some of the execstack/execmem problems. Dan From nicolas.mailhot at laposte.net Thu Feb 16 17:04:08 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 16 Feb 2006 18:04:08 +0100 Subject: More FC5 AVCs In-Reply-To: <43F49B0F.70605@redhat.com> References: <1140075385.2809.6.camel@rousalka.dyndns.org> <1140075808.2809.7.camel@rousalka.dyndns.org> <43F49B0F.70605@redhat.com> Message-ID: <1140109448.5699.5.camel@rousalka.dyndns.org> Le jeudi 16 f?vrier 2006 ? 10:32 -0500, Daniel J Walsh a ?crit : > Nicolas Mailhot wrote: > > Le jeudi 16 f?vrier 2006 ? 08:36 +0100, Nicolas Mailhot a ?crit : > > > > > >> I've attached a new AVC report at : > >> https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=124742 > >> > > > > make it > > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=124743 > > > > instead, seems I attached some old file last time > The large number of AVCs was caused by people rushing to put last minute > fixes before the FC5 Test 3 Freeze. We updated policy to fix them and > fixed some kernel problems. We are investigating some of the > execstack/execmem problems. Ok. SELinux seems awfully brittle WRT app changes (is it because no one at Red Hat runs his systems with selinux enabled?). I hope FCT3 will usable in enforcing mode, else no one will ever test it. 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 jan.kiszka at web.de Fri Feb 17 20:23:14 2006 From: jan.kiszka at web.de (Jan Kiszka) Date: Fri, 17 Feb 2006 21:23:14 +0100 Subject: [PATCH] fix and enhance openssh-selinux patch Message-ID: <43F630B2.5050709@web.de> [resent as my previous post from an unsubscribed address didn't mad it] Hi, hope I'm on the right list for submitting patches: The attached one is an add-on to the openssh-selinux patch revision 1.17. It fixes the compilation without selinux support (gcc4 complained about redefinitions of the selinux stubs) and extends the --with-selinux configure switch by the libselinux installation path (useful for cross-compiling). Jan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-selinux-fix.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From oil.pine at gmail.com Sat Feb 18 16:15:31 2006 From: oil.pine at gmail.com (pine oil) Date: Sat, 18 Feb 2006 10:15:31 -0600 Subject: caught SIGTERM, shutting down Message-ID: Hi, I upgraded FC4 files with 'yum -y ugrade' last night. After rebooting, I can't start httpd with selinux on (enforcing) with the following error message in /var/log/httpd: [Sat Feb 18 09:26:13 2006] [notice] caught SIGTERM, shutting down I have no problem starting httpd with selinux permissive. What could be the problem causing this error? pine From mgleahy at golden.net Sat Feb 18 22:10:36 2006 From: mgleahy at golden.net (Mike Leahy) Date: Sat, 18 Feb 2006 17:10:36 -0500 Subject: KDE Screensaver Message-ID: <43F79B5C.8090600@golden.net> Hello list, I just asked about this problem earlier on fedora-test-list. When I try to open the screensaver settings in Fedora test list, I got a message related to denied access to libGL.so.1. Rahul clued me into realizing that this is an SELinux issue. I set SELinux to permissive, and this allowed me to open/edit the KDE screensaver settings. Is there anything I should do to try changing the policies and/or is this already a known issue? Thanks for any suggestions, Mike type=USER_AUTH msg=audit(1140153148.074:1925): user pid=11876 uid=500 auid=500 msg='PAM: authentication acct=root : exe="/bin/su" (hostname=?, addr=?, terminal=pts/5 res=success)' type=USER_ACCT msg=audit(1140153148.074:1926): user pid=11876 uid=500 auid=500 msg='PAM: accounting acct=root : exe="/bin/su" (hostname=?, addr=?, terminal=pts/5 res=success)' type=USER_START msg=audit(1140153148.190:1927): user pid=11876 uid=500 auid=500 msg='PAM: session open acct=root : exe="/bin/su" (hostname=?, addr=?, terminal=pts/5 res=success)' type=CRED_ACQ msg=audit(1140153148.190:1928): user pid=11876 uid=500 auid=500 msg='PAM: setcred acct=root : exe="/bin/su" (hostname=?, addr=?, terminal=pts/5 res=success)' type=AVC msg=audit(1140153183.272:1929): avc: denied { execstack } for pid=11897 comm="kcmshell" scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process type=SYSCALL msg=audit(1140153183.272:1929): arch=40000003 syscall=125 success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 pid=11897 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" type=AVC msg=audit(1140153183.272:1930): avc: denied { execstack } for pid=11897 comm="kcmshell" scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process type=SYSCALL msg=audit(1140153183.272:1930): arch=40000003 syscall=125 success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 pid=11897 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" type=AVC msg=audit(1140153211.694:1931): avc: denied { execstack } for pid=11900 comm="kcmshell" scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process type=SYSCALL msg=audit(1140153211.694:1931): arch=40000003 syscall=125 success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 pid=11900 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" type=AVC msg=audit(1140153211.694:1932): avc: denied { execstack } for pid=11900 comm="kcmshell" scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process type=SYSCALL msg=audit(1140153211.694:1932): arch=40000003 syscall=125 success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 pid=11900 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" type=AVC msg=audit(1140153246.196:1933): avc: denied { execstack } for pid=11903 comm="kcmshell" scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process type=SYSCALL msg=audit(1140153246.196:1933): arch=40000003 syscall=125 success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 pid=11903 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" type=AVC msg=audit(1140153246.196:1934): avc: denied { execstack } for pid=11903 comm="kcmshell" scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process type=SYSCALL msg=audit(1140153246.196:1934): arch=40000003 syscall=125 success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 pid=11903 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" From russell at coker.com.au Sun Feb 19 02:42:08 2006 From: russell at coker.com.au (Russell Coker) Date: Sun, 19 Feb 2006 13:42:08 +1100 Subject: /sbin/restorecon and hard links In-Reply-To: <1140014693.14253.376.camel@moss-spartans.epoch.ncsc.mil> References: <1140009569.2761.34.camel@otto> <20060215143326.GI5657@angus.ind.WPI.EDU> <1140014693.14253.376.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200602191342.15573.russell@coker.com.au> On Thursday 16 February 2006 01:44, Stephen Smalley wrote: > issues. ?su has its own issues irrespective of SELinux; never su to an > untrusted account. It should be safe if you login at the console and run "exec su - hostile", that way the shell from your account has already terminated before the su program runs anything on behalf of the hostile user. The same goes for running "exec su" from an xterm. If you ssh as a non-root user and have to su to root then you would do "exec su - root" followed by "exec su - hostile" Also it should be safe to do "su hostile -c command" as there is special-case code in recent versions of the su program in Fedora to drop the controlling tty when the -c option is used. But apart from these cases, don't su to a hostile account. -- 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 selinux at gmail.com Sun Feb 19 17:01:46 2006 From: selinux at gmail.com (Tom London) Date: Sun, 19 Feb 2006 09:01:46 -0800 Subject: suspend, ntpd and hald.... Message-ID: <4c4ba1530602190901t35716ddar4dac0a250cf66fe@mail.gmail.com> Running latest rawhide, targeted/enforcing. Testing the 'you don't need shutdown, suspend is just fine' item in the System menu, I get this when I resume: ---- type=PATH msg=audit(02/19/2006 08:52:46.096:18) : item=1 flags=follow,open inode=1045689 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 type=PATH msg=audit(02/19/2006 08:52:46.096:18) : item=0 name=/usr/sbin/ntpdate flags=follow,open inode=5802372 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(02/19/2006 08:52:46.096:18) : cwd=/ type=AVC_PATH msg=audit(02/19/2006 08:52:46.096:18) : path=/dev/null type=SYSCALL msg=audit(02/19/2006 08:52:46.096:18) : arch=i386 syscall=execve success=yes exit=0 a0=9582458 a1=9583320 a2=95841b0 a3=9583838 items=2 pid=3169 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=ntpdate exe=/usr/sbin/ntpdate type=AVC msg=audit(02/19/2006 08:52:46.096:18) : avc: denied { use } for pid=3169 comm=ntpdate name=null dev=tmpfs ino=1151 scontext=system_u:system_r:ntpd_t:s0 tcontext=system_u:system_r:hald_t:s0 tclass=fd ---- type=PATH msg=audit(02/19/2006 08:53:01.082:19) : item=1 flags=follow,open inode=1045689 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 type=PATH msg=audit(02/19/2006 08:53:01.082:19) : item=0 name=/usr/sbin/ntpd flags=follow,open inode=5791501 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(02/19/2006 08:53:01.082:19) : cwd=/ type=AVC_PATH msg=audit(02/19/2006 08:53:01.082:19) : path=/dev/null type=AVC_PATH msg=audit(02/19/2006 08:53:01.082:19) : path=/dev/null type=AVC_PATH msg=audit(02/19/2006 08:53:01.082:19) : path=/dev/null type=SYSCALL msg=audit(02/19/2006 08:53:01.082:19) : arch=i386 syscall=execve success=yes exit=0 a0=8a74750 a1=8a74a60 a2=8a74c88 a3=8a746b0 items=2 pid=3172 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=ntpd exe=/usr/sbin/ntpd type=AVC msg=audit(02/19/2006 08:53:01.082:19) : avc: denied { use } for pid=3172 comm=ntpd name=null dev=tmpfs ino=1151 scontext=system_u:system_r:ntpd_t:s0 tcontext=system_u:system_r:hald_t:s0 tclass=fd type=AVC msg=audit(02/19/2006 08:53:01.082:19) : avc: denied { use } for pid=3172 comm=ntpd name=null dev=tmpfs ino=1151 scontext=system_u:system_r:ntpd_t:s0 tcontext=system_u:system_r:hald_t:s0 tclass=fd type=AVC msg=audit(02/19/2006 08:53:01.082:19) : avc: denied { use } for pid=3172 comm=ntpd name=null dev=tmpfs ino=1151 scontext=system_u:system_r:ntpd_t:s0 tcontext=system_u:system_r:hald_t:s0 tclass=fd Not quite sure I understand this.... a file descriptor leak? tom -- Tom London From gnu at wraith.sf.ca.us Sun Feb 19 17:07:51 2006 From: gnu at wraith.sf.ca.us (gnu not unix) Date: Sun, 19 Feb 2006 09:07:51 -0800 Subject: suspend, ntpd and hald.... In-Reply-To: Your message of "Sun, 19 Feb 2006 09:01:46 PST." <4c4ba1530602190901t35716ddar4dac0a250cf66fe@mail.gmail.com> Message-ID: <200602191707.k1JH7pMD018559@ring.wraith.sf.ca.us> In message <4c4ba1530602190901t35716ddar4dac0a250cf66fe at mail.gmail.com> you wri te: >Running latest rawhide, targeted/enforcing. >Testing the 'you don't need shutdown, suspend is just fine' item in >the System menu, I get this when I resume: (...) >comm=ntpdate exe=/usr/sbin/ntpdate This looks like ntpdate is attempting to run... (...) >name=/usr/sbin/ntpd flags=follow,open inode=5791501 dev=fd:00 And this looks like ntpd is already running, so you'd have a conflict there of some sort. I'm not sure it would make sense to run ntpd on a suspending system, myself, so I'd question why you're running that. ../Steven From selinux at gmail.com Sun Feb 19 17:27:06 2006 From: selinux at gmail.com (Tom London) Date: Sun, 19 Feb 2006 09:27:06 -0800 Subject: suspend, ntpd and hald.... In-Reply-To: <200602191707.k1JH7pMD018559@ring.wraith.sf.ca.us> References: <4c4ba1530602190901t35716ddar4dac0a250cf66fe@mail.gmail.com> <200602191707.k1JH7pMD018559@ring.wraith.sf.ca.us> Message-ID: <4c4ba1530602190927y249ad2adj31ab49eb71f5362b@mail.gmail.com> On 2/19/06, gnu not unix wrote: > And this looks like ntpd is already running, so you'd > have a conflict there of some sort. I'm not sure it would > make sense to run ntpd on a suspending system, myself, > so I'd question why you're running that. > > ../Steven Well, this is the first time I've tried to suspend (instead of shutting down) ;-) Does it make sense for 'suspend' to kill off ntpd and for 'resume' to restart it, sort of like init does? tom -- Tom London From gyromagnetic at gmail.com Mon Feb 20 14:44:24 2006 From: gyromagnetic at gmail.com (gf) Date: Mon, 20 Feb 2006 07:44:24 -0700 Subject: error in 'make load' Message-ID: Hi, I am trying to update the httpd policy in selinux to allow access to port 8443. I thought that I could add the line portcon tcp 8443 system_u:object_r:http_port_t to the file /etc/selinux/targeted/src/policy/net_contents and recompile. My first step was to download the sources: selinux-policy-targeted-sources-1.17.30-2.110.rpm and install. To check whether or not everthing was working, I tried the following without altering any files: [$ /etc/selinux/targeted/src/policy]:make load mkdir -p /etc/selinux/targeted/policy /usr/bin/checkpolicy -o /etc/selinux/targeted/policy/policy.18 policy.conf /usr/bin/checkpolicy: loading policy configuration from policy.conf tmp/program_used_flags.te:2:ERROR 'syntax error' at token '/etc/selinux/targeted/src/policy/domains/program' on line 1164: /etc/selinux/targeted/src/policy/domains/program #line 1 "tmp/program_used_flags.te" /usr/bin/checkpolicy: error(s) encountered while parsing configuration make: *** [/etc/selinux/targeted/policy/policy.18] Error 1 I am a newbie with regard to selinux and would really appreciate some help diagnosing and correcting this error so that I can make my desired changes. I am using Scientific Linux 4 (a variant of RHEL4). Thanks for your help. -g From bruno at wolff.to Mon Feb 20 15:57:09 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 20 Feb 2006 09:57:09 -0600 Subject: Why is only 127.0.0.1 (out of 127.0.0.0/8) a node_lo_t in policy? Message-ID: <20060220155709.GA20686@wolff.to> I was trying to understand selinux better and was looking through the policy sources and noticed that out of the loopback address space only 127.0.0.1 was given a local node type with the following: nodecon 127.0.0.1 255.255.255.255 system_u:object_r:node_lo_t I would have expected a netmask of 255.0.0.0 in the above. Is this a trade off of mistakes when people use a nonstandard network mask for loopback versus potentially having to modify the policy when running services on loopback addresses other than 127.0.0.1? (Which one might want to do to reuse a standard port number when providing local services.) From dwalsh at redhat.com Mon Feb 20 17:00:51 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 20 Feb 2006 12:00:51 -0500 Subject: [Fwd: [Fwd: Leveraging Security-Enhanced Linux in Your Data Center]] Message-ID: <43F9F5C3.2050807@redhat.com> -------- Original Message -------- Subject: Leveraging Security-Enhanced Linux in Your Data Center Date: Thu, 16 Feb 2006 14:03:25 UT From: Ziff Davis Media Reply-To: linux at enews.eweek.com To: rob at kenna.net Ziff Davis Media eSeminars: The Online Seminar Standard Leveraging Security-Enhanced Linux in Your Data Center February 23, 2005 @ 2:00 p.m. Eastern/11:00 a.m. Pacific Duration: 60 minutes Register & Attend Online http://ct.enews.eweek.com/rd/cts?d=186-3220-8-252-47659-378051-0-0-0-1 If you are unable to attend the live event you may still register and will receive an e-mail when the on-demand version becomes available. Event Overview: Security-Enhanced Linux is generating industry buzz, but what can it do for you and your data center? The threats to your systems range from well-meaning, innocent employee blunders to deliberate, well-organized attacks by foreign governments. You can reasonably and effectively leverage the latest available operating system technology to protect your data and systems. And, because it is Linux, you'll be using a well-supported, yet economical OS to mount your defenses. Join this live, interactive eSeminar and hear speakers from Red Hat and Intel discuss best practices, standards, options and platforms that create a secure network system. You'll understand the development and benefits of Security-Enhanced Linux and come away with solid and practical information you can immediately put to use. You'll have access to downloadable white papers and other information you can use. Join us for this event and you'll learn: * How tools like Position Independent Executables protect your servers * How to protect against exploitable application security weaknesses * How Execute Disable protects against buffer overflow attacks * What application families and hardware suites can take advantage of Security-Enhanced Linux * Why Security-Enhanced Linux is safe, practical and necessary * Which capabilities in the new emerging Intel platforms will help with deploying security in the enterprise environment Featured Speakers: Reinier Tuinzing, World Wide Government Market Segment Marketing Manager, Customer Solutions Group - Intel Corporation Chris Runge, Technical Director, Red Hat Government - Red Hat, Inc. Frank Derfler, VP, Market Experts Group - Ziff Davis Media Sponsored by Red Hat, Inc. & Intel Corporation Register & Attend Online http://ct.enews.eweek.com/rd/cts?d=186-3220-8-252-47659-378051-0-0-0-1 Please visit www.eSeminarslive.com for a complete list of upcoming Ziff Davis Internet eSeminars. If you have already registered for these eSeminars, please ignore this message. Feel free to pass this e-mail along to other colleagues on your team who may have an interest in attending the eSeminar above. If you have problems with your registration, send e-mail to: mailto:eSeminars at ziffdavis.com ========================================================= eNewsletter Information ========================================================= You are subscribed to this newsletter with the e-mail address rob at kenna.net. TO UNSUBSCRIBE, click here: http://ct.enews.eweek.com/rd/cts?d=186-3220-8-252-47659-378054-0-0-0-1&email=rob at kenna.net To change your HTML/text preferences, change your e-mail address or subscribe to other eNewsletters from Ziff Davis Media, click here: http://ct.enews.eweek.com/rd/cts?d=186-3220-8-252-47659-378057-0-0-0-1 Copyright (c) 2006 Ziff Davis Media Inc. All Rights Reserved. Ziff Davis Media Inc., 28 East 28th Street, New York, NY 10016 -- Robert Kenna / Red Hat Sr Product Mgr - Storage 10 Technology Park Drive Westford, MA 01886 o: (978) 392-2410 (x22410) f: (978) 392-1001 c: (978) 771-6314 rkenna at redhat.com From dwalsh at redhat.com Mon Feb 20 20:05:18 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 20 Feb 2006 15:05:18 -0500 Subject: caught SIGTERM, shutting down In-Reply-To: References: Message-ID: <43FA20FE.6000007@redhat.com> pine oil wrote: > Hi, > > I upgraded FC4 files with 'yum -y ugrade' last night. > > After rebooting, I can't start httpd with selinux on (enforcing) with > the following error message in /var/log/httpd: > [Sat Feb 18 09:26:13 2006] [notice] caught SIGTERM, shutting down > > I have no problem starting httpd with selinux permissive. > > What could be the problem causing this error? > > pine > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Do you see avc messages in /var/log/messages or /var/log/audit/audit.log? From dwalsh at redhat.com Mon Feb 20 20:08:21 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 20 Feb 2006 15:08:21 -0500 Subject: KDE Screensaver In-Reply-To: <43F79B5C.8090600@golden.net> References: <43F79B5C.8090600@golden.net> Message-ID: <43FA21B5.8090807@redhat.com> Mike Leahy wrote: > Hello list, > > I just asked about this problem earlier on fedora-test-list. When I > try to open the screensaver settings in Fedora test list, I got a > message related to denied access to libGL.so.1. Rahul clued me into > realizing that this is an SELinux issue. I set SELinux to permissive, > and this allowed me to open/edit the KDE screensaver settings. > > Is there anything I should do to try changing the policies and/or is > this already a known issue? If you really want this you can setsebool -P allow_execstack=1 You should report these as bugzilla's as they are potential security problems . There is little if any reason to ever have an application requiring execstack. http://people.redhat.com/drepper/selinux-mem.html Dan > > Thanks for any suggestions, > Mike > > type=USER_AUTH msg=audit(1140153148.074:1925): user pid=11876 uid=500 > auid=500 msg='PAM: authentication acct=root : exe="/bin/su" > (hostname=?, addr=?, terminal=pts/5 res=success)' > type=USER_ACCT msg=audit(1140153148.074:1926): user pid=11876 uid=500 > auid=500 msg='PAM: accounting acct=root : exe="/bin/su" (hostname=?, > addr=?, terminal=pts/5 res=success)' > type=USER_START msg=audit(1140153148.190:1927): user pid=11876 uid=500 > auid=500 msg='PAM: session open acct=root : exe="/bin/su" (hostname=?, > addr=?, terminal=pts/5 res=success)' > type=CRED_ACQ msg=audit(1140153148.190:1928): user pid=11876 uid=500 > auid=500 msg='PAM: setcred acct=root : exe="/bin/su" (hostname=?, > addr=?, terminal=pts/5 res=success)' > type=AVC msg=audit(1140153183.272:1929): avc: denied { execstack } > for pid=11897 comm="kcmshell" > scontext=user_u:system_r:unconfined_t:s0 > tcontext=user_u:system_r:unconfined_t:s0 tclass=process > type=SYSCALL msg=audit(1140153183.272:1929): arch=40000003 syscall=125 > success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 > pid=11897 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 > egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" > type=AVC msg=audit(1140153183.272:1930): avc: denied { execstack } > for pid=11897 comm="kcmshell" > scontext=user_u:system_r:unconfined_t:s0 > tcontext=user_u:system_r:unconfined_t:s0 tclass=process > type=SYSCALL msg=audit(1140153183.272:1930): arch=40000003 syscall=125 > success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 > pid=11897 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 > egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" > type=AVC msg=audit(1140153211.694:1931): avc: denied { execstack } > for pid=11900 comm="kcmshell" > scontext=user_u:system_r:unconfined_t:s0 > tcontext=user_u:system_r:unconfined_t:s0 tclass=process > type=SYSCALL msg=audit(1140153211.694:1931): arch=40000003 syscall=125 > success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 > pid=11900 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 > egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" > type=AVC msg=audit(1140153211.694:1932): avc: denied { execstack } > for pid=11900 comm="kcmshell" > scontext=user_u:system_r:unconfined_t:s0 > tcontext=user_u:system_r:unconfined_t:s0 tclass=process > type=SYSCALL msg=audit(1140153211.694:1932): arch=40000003 syscall=125 > success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 > pid=11900 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 > egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" > type=AVC msg=audit(1140153246.196:1933): avc: denied { execstack } > for pid=11903 comm="kcmshell" > scontext=user_u:system_r:unconfined_t:s0 > tcontext=user_u:system_r:unconfined_t:s0 tclass=process > type=SYSCALL msg=audit(1140153246.196:1933): arch=40000003 syscall=125 > success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 > pid=11903 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 > egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" > type=AVC msg=audit(1140153246.196:1934): avc: denied { execstack } > for pid=11903 comm="kcmshell" > scontext=user_u:system_r:unconfined_t:s0 > tcontext=user_u:system_r:unconfined_t:s0 tclass=process > type=SYSCALL msg=audit(1140153246.196:1934): arch=40000003 syscall=125 > success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 > pid=11903 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 > egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" > > -- > 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 Feb 20 20:16:20 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 20 Feb 2006 15:16:20 -0500 Subject: error in 'make load' In-Reply-To: References: Message-ID: <43FA2394.8030209@redhat.com> gf wrote: > Hi, > I am trying to update the httpd policy in selinux to allow access to port 8443. > I thought that I could add the line > portcon tcp 8443 system_u:object_r:http_port_t > to the file > /etc/selinux/targeted/src/policy/net_contents > and recompile. > > My first step was to download the sources: > selinux-policy-targeted-sources-1.17.30-2.110.rpm > and install. > > To check whether or not everthing was working, I tried the following > without altering any files: > > [$ /etc/selinux/targeted/src/policy]:make load > mkdir -p /etc/selinux/targeted/policy > /usr/bin/checkpolicy -o /etc/selinux/targeted/policy/policy.18 policy.conf > /usr/bin/checkpolicy: loading policy configuration from policy.conf > tmp/program_used_flags.te:2:ERROR 'syntax error' at token > '/etc/selinux/targeted/src/policy/domains/program' on line 1164: > /etc/selinux/targeted/src/policy/domains/program > #line 1 "tmp/program_used_flags.te" > /usr/bin/checkpolicy: error(s) encountered while parsing configuration > make: *** [/etc/selinux/targeted/policy/policy.18] Error 1 > > > I am a newbie with regard to selinux and would really appreciate some > help diagnosing and correcting this error so that I can make my > desired changes. > > I am using Scientific Linux 4 (a variant of RHEL4). > > Thanks for your help. > > First can you upgrade to selinux-policy-targeted*1.17.30-2.126.rpm THen try again. It is available on ftp://people.redhat.com/dwalsh/SELinux/RHEL4 You also need to grab the policycoreutils from there also. > -g > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From gyromagnetic at gmail.com Mon Feb 20 22:06:12 2006 From: gyromagnetic at gmail.com (gf) Date: Mon, 20 Feb 2006 15:06:12 -0700 Subject: error in 'make load' In-Reply-To: <43FA2394.8030209@redhat.com> References: <43FA2394.8030209@redhat.com> Message-ID: On 2/20/06, Daniel J Walsh wrote: > gf wrote: > > Hi, > > I am trying to update the httpd policy in selinux to allow access to port 8443. > > I thought that I could add the line > > portcon tcp 8443 system_u:object_r:http_port_t > > to the file > > /etc/selinux/targeted/src/policy/net_contents > > and recompile. > > > > My first step was to download the sources: > > selinux-policy-targeted-sources-1.17.30-2.110.rpm > > and install. > > > > To check whether or not everthing was working, I tried the following > > without altering any files: > > > > [$ /etc/selinux/targeted/src/policy]:make load > > mkdir -p /etc/selinux/targeted/policy > > /usr/bin/checkpolicy -o /etc/selinux/targeted/policy/policy.18 policy.conf > > /usr/bin/checkpolicy: loading policy configuration from policy.conf > > tmp/program_used_flags.te:2:ERROR 'syntax error' at token > > '/etc/selinux/targeted/src/policy/domains/program' on line 1164: > > /etc/selinux/targeted/src/policy/domains/program > > #line 1 "tmp/program_used_flags.te" > > /usr/bin/checkpolicy: error(s) encountered while parsing configuration > > make: *** [/etc/selinux/targeted/policy/policy.18] Error 1 > > > > > > I am a newbie with regard to selinux and would really appreciate some > > help diagnosing and correcting this error so that I can make my > > desired changes. > > > > I am using Scientific Linux 4 (a variant of RHEL4). > > > > Thanks for your help. > > > > > First can you upgrade to > > selinux-policy-targeted*1.17.30-2.126.rpm > THen try again. > > It is available on ftp://people.redhat.com/dwalsh/SELinux/RHEL4 > > You also need to grab the policycoreutils from there also. > > -g > > Hi, Thanks for the response. I downloaded the following files from the site you pointed to selinux-policy-targeted-1.17.30-2.126.noarch.rpm selinux-policy-targeted-sources-1.17.30-2.126.noarch.rpm policycoreutils-1.18.1-4.9.i386.rpm and upgraded my distribution. Before installing the *sources* rpm, I removed /etc/selinux/targeted/src completely to make sure that there were no residual edited files. Unfortunately, when I run 'make load', I run into the same problem as I described earlier. Do you have any other advice for things that I can try? Thanks. -g From mgleahy at golden.net Mon Feb 20 22:42:34 2006 From: mgleahy at golden.net (Mike Leahy) Date: Mon, 20 Feb 2006 17:42:34 -0500 Subject: KDE Screensaver In-Reply-To: <43FA21B5.8090807@redhat.com> References: <43F79B5C.8090600@golden.net> <43FA21B5.8090807@redhat.com> Message-ID: <43FA45DA.4020800@golden.net> Would this be something to report as a KDE bug then? Daniel J Walsh wrote: > Mike Leahy wrote: >> Hello list, >> >> I just asked about this problem earlier on fedora-test-list. When I >> try to open the screensaver settings in Fedora test list, I got a >> message related to denied access to libGL.so.1. Rahul clued me into >> realizing that this is an SELinux issue. I set SELinux to permissive, >> and this allowed me to open/edit the KDE screensaver settings. >> >> Is there anything I should do to try changing the policies and/or is >> this already a known issue? > If you really want this you can setsebool -P allow_execstack=1 > You should report these as bugzilla's as they are potential security > problems . There is little if any reason to ever have an application > requiring execstack. > > http://people.redhat.com/drepper/selinux-mem.html > > Dan >> >> Thanks for any suggestions, >> Mike >> >> type=USER_AUTH msg=audit(1140153148.074:1925): user pid=11876 uid=500 >> auid=500 msg='PAM: authentication acct=root : exe="/bin/su" >> (hostname=?, addr=?, terminal=pts/5 res=success)' >> type=USER_ACCT msg=audit(1140153148.074:1926): user pid=11876 uid=500 >> auid=500 msg='PAM: accounting acct=root : exe="/bin/su" (hostname=?, >> addr=?, terminal=pts/5 res=success)' >> type=USER_START msg=audit(1140153148.190:1927): user pid=11876 uid=500 >> auid=500 msg='PAM: session open acct=root : exe="/bin/su" (hostname=?, >> addr=?, terminal=pts/5 res=success)' >> type=CRED_ACQ msg=audit(1140153148.190:1928): user pid=11876 uid=500 >> auid=500 msg='PAM: setcred acct=root : exe="/bin/su" (hostname=?, >> addr=?, terminal=pts/5 res=success)' >> type=AVC msg=audit(1140153183.272:1929): avc: denied { execstack } >> for pid=11897 comm="kcmshell" >> scontext=user_u:system_r:unconfined_t:s0 >> tcontext=user_u:system_r:unconfined_t:s0 tclass=process >> type=SYSCALL msg=audit(1140153183.272:1929): arch=40000003 syscall=125 >> success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 >> pid=11897 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 >> egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" >> type=AVC msg=audit(1140153183.272:1930): avc: denied { execstack } >> for pid=11897 comm="kcmshell" >> scontext=user_u:system_r:unconfined_t:s0 >> tcontext=user_u:system_r:unconfined_t:s0 tclass=process >> type=SYSCALL msg=audit(1140153183.272:1930): arch=40000003 syscall=125 >> success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 >> pid=11897 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 >> egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" >> type=AVC msg=audit(1140153211.694:1931): avc: denied { execstack } >> for pid=11900 comm="kcmshell" >> scontext=user_u:system_r:unconfined_t:s0 >> tcontext=user_u:system_r:unconfined_t:s0 tclass=process >> type=SYSCALL msg=audit(1140153211.694:1931): arch=40000003 syscall=125 >> success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 >> pid=11900 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 >> egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" >> type=AVC msg=audit(1140153211.694:1932): avc: denied { execstack } >> for pid=11900 comm="kcmshell" >> scontext=user_u:system_r:unconfined_t:s0 >> tcontext=user_u:system_r:unconfined_t:s0 tclass=process >> type=SYSCALL msg=audit(1140153211.694:1932): arch=40000003 syscall=125 >> success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 >> pid=11900 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 >> egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" >> type=AVC msg=audit(1140153246.196:1933): avc: denied { execstack } >> for pid=11903 comm="kcmshell" >> scontext=user_u:system_r:unconfined_t:s0 >> tcontext=user_u:system_r:unconfined_t:s0 tclass=process >> type=SYSCALL msg=audit(1140153246.196:1933): arch=40000003 syscall=125 >> success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 >> pid=11903 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 >> egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" >> type=AVC msg=audit(1140153246.196:1934): avc: denied { execstack } >> for pid=11903 comm="kcmshell" >> scontext=user_u:system_r:unconfined_t:s0 >> tcontext=user_u:system_r:unconfined_t:s0 tclass=process >> type=SYSCALL msg=audit(1140153246.196:1934): arch=40000003 syscall=125 >> success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 >> pid=11903 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 >> egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" >> >> -- >> 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 Feb 21 05:11:15 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 21 Feb 2006 00:11:15 -0500 Subject: KDE Screensaver In-Reply-To: <43FA45DA.4020800@golden.net> References: <43F79B5C.8090600@golden.net> <43FA21B5.8090807@redhat.com> <43FA45DA.4020800@golden.net> Message-ID: <43FAA0F3.80405@redhat.com> Mike Leahy wrote: > Would this be something to report as a KDE bug then? > yes and point them at http://people.redhat.com/drepper/selinux-mem.html > Daniel J Walsh wrote: > >> Mike Leahy wrote: >> >>> Hello list, >>> >>> I just asked about this problem earlier on fedora-test-list. When I >>> try to open the screensaver settings in Fedora test list, I got a >>> message related to denied access to libGL.so.1. Rahul clued me into >>> realizing that this is an SELinux issue. I set SELinux to permissive, >>> and this allowed me to open/edit the KDE screensaver settings. >>> >>> Is there anything I should do to try changing the policies and/or is >>> this already a known issue? >>> >> If you really want this you can setsebool -P allow_execstack=1 >> You should report these as bugzilla's as they are potential security >> problems . There is little if any reason to ever have an application >> requiring execstack. >> >> http://people.redhat.com/drepper/selinux-mem.html >> >> Dan >> >>> Thanks for any suggestions, >>> Mike >>> >>> type=USER_AUTH msg=audit(1140153148.074:1925): user pid=11876 uid=500 >>> auid=500 msg='PAM: authentication acct=root : exe="/bin/su" >>> (hostname=?, addr=?, terminal=pts/5 res=success)' >>> type=USER_ACCT msg=audit(1140153148.074:1926): user pid=11876 uid=500 >>> auid=500 msg='PAM: accounting acct=root : exe="/bin/su" (hostname=?, >>> addr=?, terminal=pts/5 res=success)' >>> type=USER_START msg=audit(1140153148.190:1927): user pid=11876 uid=500 >>> auid=500 msg='PAM: session open acct=root : exe="/bin/su" (hostname=?, >>> addr=?, terminal=pts/5 res=success)' >>> type=CRED_ACQ msg=audit(1140153148.190:1928): user pid=11876 uid=500 >>> auid=500 msg='PAM: setcred acct=root : exe="/bin/su" (hostname=?, >>> addr=?, terminal=pts/5 res=success)' >>> type=AVC msg=audit(1140153183.272:1929): avc: denied { execstack } >>> for pid=11897 comm="kcmshell" >>> scontext=user_u:system_r:unconfined_t:s0 >>> tcontext=user_u:system_r:unconfined_t:s0 tclass=process >>> type=SYSCALL msg=audit(1140153183.272:1929): arch=40000003 syscall=125 >>> success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 >>> pid=11897 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 >>> egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" >>> type=AVC msg=audit(1140153183.272:1930): avc: denied { execstack } >>> for pid=11897 comm="kcmshell" >>> scontext=user_u:system_r:unconfined_t:s0 >>> tcontext=user_u:system_r:unconfined_t:s0 tclass=process >>> type=SYSCALL msg=audit(1140153183.272:1930): arch=40000003 syscall=125 >>> success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 >>> pid=11897 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 >>> egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" >>> type=AVC msg=audit(1140153211.694:1931): avc: denied { execstack } >>> for pid=11900 comm="kcmshell" >>> scontext=user_u:system_r:unconfined_t:s0 >>> tcontext=user_u:system_r:unconfined_t:s0 tclass=process >>> type=SYSCALL msg=audit(1140153211.694:1931): arch=40000003 syscall=125 >>> success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 >>> pid=11900 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 >>> egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" >>> type=AVC msg=audit(1140153211.694:1932): avc: denied { execstack } >>> for pid=11900 comm="kcmshell" >>> scontext=user_u:system_r:unconfined_t:s0 >>> tcontext=user_u:system_r:unconfined_t:s0 tclass=process >>> type=SYSCALL msg=audit(1140153211.694:1932): arch=40000003 syscall=125 >>> success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 >>> pid=11900 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 >>> egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" >>> type=AVC msg=audit(1140153246.196:1933): avc: denied { execstack } >>> for pid=11903 comm="kcmshell" >>> scontext=user_u:system_r:unconfined_t:s0 >>> tcontext=user_u:system_r:unconfined_t:s0 tclass=process >>> type=SYSCALL msg=audit(1140153246.196:1933): arch=40000003 syscall=125 >>> success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 >>> pid=11903 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 >>> egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" >>> type=AVC msg=audit(1140153246.196:1934): avc: denied { execstack } >>> for pid=11903 comm="kcmshell" >>> scontext=user_u:system_r:unconfined_t:s0 >>> tcontext=user_u:system_r:unconfined_t:s0 tclass=process >>> type=SYSCALL msg=audit(1140153246.196:1934): arch=40000003 syscall=125 >>> success=no exit=-13 a0=bfc01000 a1=1000 a2=1000007 a3=fffff000 items=0 >>> pid=11903 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 >>> egid=500 sgid=500 fsgid=500 comm="kcmshell" exe="/usr/bin/kdeinit" >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> >> > > -- > 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 Feb 21 05:22:28 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 21 Feb 2006 00:22:28 -0500 Subject: error in 'make load' In-Reply-To: References: <43FA2394.8030209@redhat.com> Message-ID: <43FAA394.9060206@redhat.com> gf wrote: > On 2/20/06, Daniel J Walsh wrote: > >> gf wrote: >> >>> Hi, >>> I am trying to update the httpd policy in selinux to allow access to port 8443. >>> I thought that I could add the line >>> portcon tcp 8443 system_u:object_r:http_port_t >>> to the file >>> /etc/selinux/targeted/src/policy/net_contents >>> and recompile. >>> >>> My first step was to download the sources: >>> selinux-policy-targeted-sources-1.17.30-2.110.rpm >>> and install. >>> >>> I tried it here and it worked. Do you have an up2date version of checkpolicy? Policycoreutils? I don't think your change is effecting this at all. >>> To check whether or not everthing was working, I tried the following >>> without altering any files: >>> >>> [$ /etc/selinux/targeted/src/policy]:make load >>> mkdir -p /etc/selinux/targeted/policy >>> /usr/bin/checkpolicy -o /etc/selinux/targeted/policy/policy.18 policy.conf >>> /usr/bin/checkpolicy: loading policy configuration from policy.conf >>> tmp/program_used_flags.te:2:ERROR 'syntax error' at token >>> '/etc/selinux/targeted/src/policy/domains/program' on line 1164: >>> /etc/selinux/targeted/src/policy/domains/program >>> #line 1 "tmp/program_used_flags.te" >>> /usr/bin/checkpolicy: error(s) encountered while parsing configuration >>> make: *** [/etc/selinux/targeted/policy/policy.18] Error 1 >>> >>> >>> I am a newbie with regard to selinux and would really appreciate some >>> help diagnosing and correcting this error so that I can make my >>> desired changes. >>> >>> I am using Scientific Linux 4 (a variant of RHEL4). >>> >>> Thanks for your help. >>> >>> >>> >> First can you upgrade to >> >> selinux-policy-targeted*1.17.30-2.126.rpm >> THen try again. >> >> It is available on ftp://people.redhat.com/dwalsh/SELinux/RHEL4 >> >> You also need to grab the policycoreutils from there also. >> >>> -g >>> >>> > > Hi, > Thanks for the response. > I downloaded the following files from the site you pointed to > selinux-policy-targeted-1.17.30-2.126.noarch.rpm > selinux-policy-targeted-sources-1.17.30-2.126.noarch.rpm > policycoreutils-1.18.1-4.9.i386.rpm > > and upgraded my distribution. Before installing the *sources* rpm, I > removed /etc/selinux/targeted/src completely to make sure that there > were no residual edited files. > > Unfortunately, when I run 'make load', I run into the same problem as > I described earlier. > > Do you have any other advice for things that I can try? > > Thanks. > > > -g > From russell at coker.com.au Mon Feb 20 23:06:30 2006 From: russell at coker.com.au (Russell Coker) Date: Tue, 21 Feb 2006 10:06:30 +1100 Subject: du confusion Message-ID: <200602211006.46551.russell@coker.com.au> du currently displays the total count of blocks used for the file including block(s) for XATTRs. This means that every file is reported as having a block used for the security.selinux XATTR (even though those blocks are shared extensively on typical SE Linux systems). A more useful display on SE Linux systems is to have the --apparent-size option of du enabled. I suggest that we have a default install of Fedora alias "du" to "du --apparent-size". Currently in a default install we have rm aliased to "rm -i" (and similar for mv and cp), so it seems that there is a good precedent for this sort of thing. What do you think? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From tscherf at redhat.com Tue Feb 21 06:52:37 2006 From: tscherf at redhat.com (Thorsten Scherf) Date: Tue, 21 Feb 2006 07:52:37 +0100 Subject: [Fwd: [Fwd: Leveraging Security-Enhanced Linux in Your Data Center]] In-Reply-To: <43F9F5C3.2050807@redhat.com> References: <43F9F5C3.2050807@redhat.com> Message-ID: <43FAB8B5.1040706@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Do we have any slides for this? Thorsten Daniel J Walsh wrote: > -------- Original Message -------- > Subject: Leveraging Security-Enhanced Linux in Your Data Center > Date: Thu, 16 Feb 2006 14:03:25 UT > From: Ziff Davis Media > Reply-To: linux at enews.eweek.com > To: rob at kenna.net > > > > Ziff Davis Media eSeminars: The Online Seminar Standard > > Leveraging Security-Enhanced Linux in Your Data Center > February 23, 2005 @ 2:00 p.m. Eastern/11:00 a.m. Pacific > Duration: 60 minutes > > Register & Attend Online > http://ct.enews.eweek.com/rd/cts?d=186-3220-8-252-47659-378051-0-0-0-1 > > If you are unable to attend the live event you may still register and > will receive an e-mail when the on-demand version becomes available. > > Event Overview: > Security-Enhanced Linux is generating industry buzz, but what can it do > for you and your data center? The threats to your systems range from > well-meaning, innocent employee blunders to deliberate, well-organized > attacks by foreign governments. You can reasonably and effectively > leverage the latest available operating system technology to protect > your data and systems. And, because it is Linux, you'll be using a > well-supported, yet economical OS to mount your defenses. > > Join this live, interactive eSeminar and hear speakers from Red Hat and > Intel discuss best practices, standards, options and platforms that > create a secure network system. You'll understand the development and > benefits of Security-Enhanced Linux and come away with solid and > practical information you can immediately put to use. You'll have access > to downloadable white papers and other information you can use. > > Join us for this event and you'll learn: > > * How tools like Position Independent Executables protect your servers > * How to protect against exploitable application security weaknesses > * How Execute Disable protects against buffer overflow attacks > * What application families and hardware suites can take advantage > of Security-Enhanced Linux > * Why Security-Enhanced Linux is safe, practical and necessary > * Which capabilities in the new emerging Intel platforms will help > with deploying security in the enterprise environment > > Featured Speakers: > Reinier Tuinzing, World Wide Government Market Segment Marketing > Manager, Customer Solutions Group - Intel Corporation > Chris Runge, Technical Director, Red Hat Government - Red Hat, Inc. > Frank Derfler, VP, Market Experts Group - Ziff Davis Media > > Sponsored by Red Hat, Inc. & Intel Corporation > > Register & Attend Online > http://ct.enews.eweek.com/rd/cts?d=186-3220-8-252-47659-378051-0-0-0-1 > > Please visit www.eSeminarslive.com > for a complete list of upcoming Ziff Davis Internet eSeminars. > > If you have already registered for these eSeminars, please ignore this > message. Feel free to pass this e-mail along to other colleagues on > your team who may have an interest in attending the eSeminar above. If > you have problems with your registration, send e-mail to: > mailto:eSeminars at ziffdavis.com > > ========================================================= > eNewsletter Information > ========================================================= > You are subscribed to this newsletter with the e-mail address > rob at kenna.net. > TO UNSUBSCRIBE, click here: > http://ct.enews.eweek.com/rd/cts?d=186-3220-8-252-47659-378054-0-0-0-1&email=rob at kenna.net > > > To change your HTML/text preferences, change your e-mail > address or subscribe to other eNewsletters from Ziff Davis > Media, click here: > http://ct.enews.eweek.com/rd/cts?d=186-3220-8-252-47659-378057-0-0-0-1 > > Copyright (c) 2006 Ziff Davis Media Inc. All Rights Reserved. Ziff Davis > Media Inc., 28 East 28th Street, New York, NY 10016 > > - -- Thorsten Scherf Mobile : ++49 172 61 32 548 RHCA, RHCSS Fax : ++49 2064 470 564 GPG KEY: 0x3B9280BB - 92BF AA4C 082B F5DD FB28 47CC C1F9 282D 3B92 80BB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD+ri0wfkoLTuSgLsRAoPpAKD3xe0gDgK43TSClU15YiTErFI1EgCfWxYE xS5mMyN/MwFSBJxfDxBsL2s= =FTyW -----END PGP SIGNATURE----- From gyromagnetic at gmail.com Tue Feb 21 16:28:57 2006 From: gyromagnetic at gmail.com (gf) Date: Tue, 21 Feb 2006 09:28:57 -0700 Subject: error in 'make load' In-Reply-To: <43FAA394.9060206@redhat.com> References: <43FA2394.8030209@redhat.com> <43FAA394.9060206@redhat.com> Message-ID: On 2/20/06, Daniel J Walsh wrote: [snip] > I tried it here and it worked. > > Do you have an up2date version of checkpolicy? Policycoreutils? > > I don't think your change is effecting this at all. > I'm confused. If you read my latest email, I wrote that I downloaded and installed the files you recommended. The installed packages are now policycoreutils-1.18.1-4.9 checkpolicy-1.17.5-1 selinux-policy-targeted-1.17.30-2.126 policycoreutils-1.18.1-4.9 Obviously, I can't explain why you (and undoubtedly others) have a working version. I was looking for clues as to why mine isn't. Thanks for your input. -g From sds at tycho.nsa.gov Tue Feb 21 16:55:07 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 21 Feb 2006 11:55:07 -0500 Subject: error in 'make load' In-Reply-To: References: Message-ID: <1140540907.31467.40.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2006-02-20 at 07:44 -0700, gf wrote: > Hi, > I am trying to update the httpd policy in selinux to allow access to port 8443. > I thought that I could add the line > portcon tcp 8443 system_u:object_r:http_port_t > to the file > /etc/selinux/targeted/src/policy/net_contents > and recompile. > > My first step was to download the sources: > selinux-policy-targeted-sources-1.17.30-2.110.rpm > and install. > > To check whether or not everthing was working, I tried the following > without altering any files: > > [$ /etc/selinux/targeted/src/policy]:make load > mkdir -p /etc/selinux/targeted/policy > /usr/bin/checkpolicy -o /etc/selinux/targeted/policy/policy.18 policy.conf > /usr/bin/checkpolicy: loading policy configuration from policy.conf > tmp/program_used_flags.te:2:ERROR 'syntax error' at token > '/etc/selinux/targeted/src/policy/domains/program' on line 1164: > /etc/selinux/targeted/src/policy/domains/program > #line 1 "tmp/program_used_flags.te" > /usr/bin/checkpolicy: error(s) encountered while parsing configuration > make: *** [/etc/selinux/targeted/policy/policy.18] Error 1 Sounds like a bug in the policy Makefile in the generation of the policy.conf file, as that string ('/etc/selinux/targeted/src/policy/domains/program') shouldn't appear in it. Provide more context please, e.g. the lines around line 1164 of the policy.conf file. -- Stephen Smalley National Security Agency From stephen.walton at csun.edu Wed Feb 22 00:14:20 2006 From: stephen.walton at csun.edu (Stephen Walton) Date: Tue, 21 Feb 2006 16:14:20 -0800 Subject: du confusion In-Reply-To: <200602211006.46551.russell@coker.com.au> References: <200602211006.46551.russell@coker.com.au> Message-ID: <43FBACDC.8060907@csun.edu> Russell Coker wrote: >I suggest that we have a default install of Fedora >alias "du" to "du --apparent-size". > > Sounds OK to me. >Currently in a default install we have rm aliased to "rm -i" (and similar for >mv and cp), > Only for root. That is, these aliases are in /root/.bashrc but not in /etc/bashrc or any other global file. From linux_4ever at yahoo.com Wed Feb 22 19:17:19 2006 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 22 Feb 2006 11:17:19 -0800 (PST) Subject: Red Hat SE Linux Opening Message-ID: <20060222191719.28177.qmail@web51502.mail.yahoo.com> Hi, I just wanted to let everyone know that Red Hat has a SE Linux programming job available. If you're interested, please take a look: http://redhat.hrdpt.com/cgi-bin/a/highlightjob.cgi?jobid=1049 -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From russell at coker.com.au Thu Feb 23 00:35:27 2006 From: russell at coker.com.au (Russell Coker) Date: Thu, 23 Feb 2006 11:35:27 +1100 Subject: Curious Behavior doing routine redirection of ping output to (selinux: message 2 of 12) file... In-Reply-To: References: <43A8E5B0.8040902@funchords.com> <1136300437.27632.40.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200602231136.05781.russell@coker.com.au> On Wednesday 04 January 2006 06:11, Gregory Maxwell wrote: > 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... Mysterious failures are a bad thing. But the performance hit of proxying the data would also be bad. Also note that there are some unusual features that some programs may rely on, for example when you see the following you may think that the file is append-only: program > output However that is not the case. The program can seek in the file, EG it can seek back to 0 to re-write the file if it wishes. program < input The above command permits seeking in the input file to read from different locations. Some programs rely on this type of functionality, for example the mpg123 program to play MP3 files would do exactly that. Commands such as "zcat file.mp3.gz | mpg123 -" didn't work because seeks failed on the pipe. I wrote a patch for mpg123 that used fopen() and fseek() as the stdio buffers were large enough to allow the 100 byte reverse seeks that mpg123 relied on. Tracking down many programs that are similarly buggy and writing work-arounds for them would not be fun. -- 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 laisve at gmail.com Thu Feb 23 13:08:26 2006 From: laisve at gmail.com (Dovydas Sankauskas) Date: Thu, 23 Feb 2006 13:08:26 +0000 Subject: context not inherited on mounted FS Message-ID: <1d3e8bf0602230508h3392a2d5w@mail.gmail.com> I have dir $ l -dZ /home/dovydas/muzika drwxrwxr-x dovydas dovydas user_u:object_r:user_home_t /home/dovydas/muzika/ I mount here external usb hdd $ mount /dev/sda1 on /home/dovydas/muzika type xfs (rw,noexec) When I do $ touch /home/dovydas/muzika/sample I get $ l -Z /home/dovydas/muzika/sample -rw-rw-r-- dovydas dovydas system_u:object_r:file_t /home/dovydas/muzika/sample Why context is not inherited? How can I solve this problem? I saw this problem, when I tried to connect to my computer via ftp. I simply can not see file "sample" via ftp. I can create a subdir, but i can not see it. All other dirs are allright, except this one /home/dovydas/muzika, which is mounted external hdd. -- Dovydas Sankauskas From sds at tycho.nsa.gov Thu Feb 23 13:22:57 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 23 Feb 2006 08:22:57 -0500 Subject: Apache/PHP module boot restriction? In-Reply-To: References: Message-ID: <1140700977.21179.12.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-02-22 at 16:41 -0800, Andrew JH Ring wrote: > I've recently set up a Fedora Core 4 web server running Apache 2.2.0 > with PHP 5.1.2. I've managed to get Apache loading the module, after > setting libphp5.so to shlib_t, however Apache seems to still be unable > to access the module during boot. I'm getting a Cannot load libphp5 > cannot restore segment prot after reloc. Is this a known problem, and > if so, how is it fixed? cc'd fedora-selinux-list as well above, since you mentioned you were using FC4. This usually indicates a text relocation, which is undesirable if it can be avoided. The stock FC4 php doesn't appear to have any text relocations in its libphp (readelf -d libphp5.so.1 | grep TEXTREL). Possibly it has a patch to avoid the problem. Ideally, it would be best if you could similarly patch or fix the build for PHP 5.1.2. If you truly need to allow it, then you can label the .so file with the texrel_shlib_t type (since you are using FC4, I used the old type name). Some discussion of the SELinux memory protection tests can be found in: http://people.redhat.com/drepper/selinux-mem.html -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu Feb 23 13:27:44 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 23 Feb 2006 08:27:44 -0500 Subject: context not inherited on mounted FS In-Reply-To: <1d3e8bf0602230508h3392a2d5w@mail.gmail.com> References: <1d3e8bf0602230508h3392a2d5w@mail.gmail.com> Message-ID: <1140701264.21179.18.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-02-23 at 13:08 +0000, Dovydas Sankauskas wrote: > I have dir > $ l -dZ /home/dovydas/muzika > drwxrwxr-x dovydas dovydas user_u:object_r:user_home_t > /home/dovydas/muzika/ > > I mount here external usb hdd > $ mount > /dev/sda1 on /home/dovydas/muzika type xfs (rw,noexec) > > When I do > $ touch /home/dovydas/muzika/sample > I get > $ l -Z /home/dovydas/muzika/sample > -rw-rw-r-- dovydas dovydas system_u:object_r:file_t > /home/dovydas/muzika/sample > > Why context is not inherited? How can I solve this problem? I saw this > problem, when I tried to connect to my computer via ftp. I simply can > not see file "sample" via ftp. I can create a subdir, but i can not > see it. All other dirs are allright, except this one > /home/dovydas/muzika, which is mounted external hdd. First, a mounted directory won't inherit from the mount point directory - it has its own extended attribute. Second, xfs has a known issue with SELinux labeling in 2.6.14 and 2.6.15, which has been fixed upstream for 2.6.16. See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176600 You might want to add a comment to that bug noting that you need xfs/SELinux support and asking about getting the xfs patches incorporated into a future FC4 kernel update (assuming you are using FC4). But they might just wait until 2.6.16 comes out. -- Stephen Smalley National Security Agency From jorton at redhat.com Thu Feb 23 14:40:39 2006 From: jorton at redhat.com (Joe Orton) Date: Thu, 23 Feb 2006 14:40:39 +0000 Subject: du confusion In-Reply-To: <200602211006.46551.russell@coker.com.au> References: <200602211006.46551.russell@coker.com.au> Message-ID: <20060223144038.GA3972@redhat.com> On Tue, Feb 21, 2006 at 10:06:30AM +1100, Russell Coker wrote: > du currently displays the total count of blocks used for the file including > block(s) for XATTRs. This means that every file is reported as having a > block used for the security.selinux XATTR (even though those blocks are > shared extensively on typical SE Linux systems). > > A more useful display on SE Linux systems is to have the --apparent-size > option of du enabled. I suggest that we have a default install of Fedora > alias "du" to "du --apparent-size". That would be really evil, du is *supposed* to report disk usage not file sizes. It's always been true that disk usage and file size can diverge, that's why du and ls are separate tools. joe From jorton at redhat.com Thu Feb 23 14:42:57 2006 From: jorton at redhat.com (Joe Orton) Date: Thu, 23 Feb 2006 14:42:57 +0000 Subject: Apache/PHP module boot restriction? In-Reply-To: <1140700977.21179.12.camel@moss-spartans.epoch.ncsc.mil> References: <1140700977.21179.12.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20060223144257.GB3972@redhat.com> On Thu, Feb 23, 2006 at 08:22:57AM -0500, Stephen Smalley wrote: > On Wed, 2006-02-22 at 16:41 -0800, Andrew JH Ring wrote: > > I've recently set up a Fedora Core 4 web server running Apache 2.2.0 > > with PHP 5.1.2. I've managed to get Apache loading the module, after > > setting libphp5.so to shlib_t, however Apache seems to still be unable > > to access the module during boot. I'm getting a Cannot load libphp5 > > cannot restore segment prot after reloc. Is this a known problem, and > > if so, how is it fixed? > > cc'd fedora-selinux-list as well above, since you mentioned you were > using FC4. > > This usually indicates a text relocation, which is undesirable if it can > be avoided. The stock FC4 php doesn't appear to have any text > relocations in its libphp (readelf -d libphp5.so.1 | grep TEXTREL). > Possibly it has a patch to avoid the problem. You have to pass --with-pic to configure; upstream default builds non-PIC code into the DSO by default ("it's a feature!"). joe From laisve at gmail.com Thu Feb 23 15:22:08 2006 From: laisve at gmail.com (Dovydas Sankauskas) Date: Thu, 23 Feb 2006 15:22:08 +0000 Subject: context not inherited on mounted FS In-Reply-To: <1140701264.21179.18.camel@moss-spartans.epoch.ncsc.mil> References: <1d3e8bf0602230508h3392a2d5w@mail.gmail.com> <1140701264.21179.18.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1d3e8bf0602230722o4d36fecam@mail.gmail.com> Thanks you for bringing some light! :)) I think I will wait for 2.6.16 kernel and by now I will turn off SELinux. 2006/2/23, Stephen Smalley : > On Thu, 2006-02-23 at 13:08 +0000, Dovydas Sankauskas wrote: > > I have dir > > $ l -dZ /home/dovydas/muzika > > drwxrwxr-x dovydas dovydas user_u:object_r:user_home_t > > /home/dovydas/muzika/ > > > > I mount here external usb hdd > > $ mount > > /dev/sda1 on /home/dovydas/muzika type xfs (rw,noexec) > > > > When I do > > $ touch /home/dovydas/muzika/sample > > I get > > $ l -Z /home/dovydas/muzika/sample > > -rw-rw-r-- dovydas dovydas system_u:object_r:file_t > > /home/dovydas/muzika/sample > > > > Why context is not inherited? How can I solve this problem? I saw this > > problem, when I tried to connect to my computer via ftp. I simply can > > not see file "sample" via ftp. I can create a subdir, but i can not > > see it. All other dirs are allright, except this one > > /home/dovydas/muzika, which is mounted external hdd. > > First, a mounted directory won't inherit from the mount point directory > - it has its own extended attribute. Second, xfs has a known issue with > SELinux labeling in 2.6.14 and 2.6.15, which has been fixed upstream for > 2.6.16. See: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176600 > > You might want to add a comment to that bug noting that you need > xfs/SELinux support and asking about getting the xfs patches > incorporated into a future FC4 kernel update (assuming you are using > FC4). But they might just wait until 2.6.16 comes out. > > -- > Stephen Smalley > National Security Agency > > -- Dovydas Sankauskas From lamont at gurulabs.com Thu Feb 23 16:22:29 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 23 Feb 2006 09:22:29 -0700 Subject: du confusion In-Reply-To: <20060223144038.GA3972@redhat.com> References: <200602211006.46551.russell@coker.com.au> <20060223144038.GA3972@redhat.com> Message-ID: <200602230922.36050.lamont@gurulabs.com> On Thursday 23 February 2006 07:40am, Joe Orton wrote: > On Tue, Feb 21, 2006 at 10:06:30AM +1100, Russell Coker wrote: > > du currently displays the total count of blocks used for the file > > including block(s) for XATTRs. This means that every file is reported as > > having a block used for the security.selinux XATTR (even though those > > blocks are shared extensively on typical SE Linux systems). > > > > A more useful display on SE Linux systems is to have the --apparent-size > > option of du enabled. I suggest that we have a default install of Fedora > > alias "du" to "du --apparent-size". > > That would be really evil, No, it wouldn't. Even your own argument here says that. > du is *supposed* to report disk usage not > file sizes. I think you have that backwards. du shows the total of file sizes. Also, how does --apparent-size create an *inaccurate* picture here? I think you've got that backwards, too. > It's always been true that disk usage and file size can > diverge, that's why du and ls are separate tools. Actually, that's why du and df (disk free) are separate tools. Just yesterday, I was trying to install an updated kernel on one machine that I have at home that does not have SELinux enabled, due to testing I was doing recently with other filesystems that didn't have xattr support (next testing turns it back on :) ). It has a 512MB root LV and /usr, /var, /tmp & /home are all on their own LVs. There wasn't enough space on /, according to rpm. Running "du -sx /" on that home system showed that only about 220,000 KB was in use, but "df /" showed that approximately 502,000 KB was in use. I was thinking, "What the heck is going on here?" Then, it struck me, ext3. The items remaining on the root partition are almost all small files, and thousands of them (plus some directories that are taking up data blocks). It is very important to understand that difference. It would be a good idea to add --apparent-size to du, out-of-the-box. However, would that switch affect results on non SELinux systems? Those with other types of xattrs? If so, then we might want to look at having something flip that switch in and out based on getenforce state. If "Disabled", no switch; otherwise, include the --apparent-size switch. How about an alias like: alias du="du$(if [ `getenforce` != "Disabled" ]; then echo " --apparent-size"; fi) That's just off the top of my head and not tested, so please, refine it if needed. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Feb 23 18:35:23 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 23 Feb 2006 13:35:23 -0500 Subject: du confusion In-Reply-To: Your message of "Thu, 23 Feb 2006 14:40:39 GMT." <20060223144038.GA3972@redhat.com> References: <200602211006.46551.russell@coker.com.au> <20060223144038.GA3972@redhat.com> Message-ID: <200602231835.k1NIZNRr013994@turing-police.cc.vt.edu> On Thu, 23 Feb 2006 14:40:39 GMT, Joe Orton said: > That would be really evil, du is *supposed* to report disk usage not > file sizes. It's always been true that disk usage and file size can > diverge, that's why du and ls are separate tools. 'du' doesn't report on the space used by the inode either - and on many filesystems with many small files, the inode is a significant chunk of the used space.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From jorton at redhat.com Thu Feb 23 19:01:57 2006 From: jorton at redhat.com (Joe Orton) Date: Thu, 23 Feb 2006 19:01:57 +0000 Subject: du confusion In-Reply-To: <200602230922.36050.lamont@gurulabs.com> References: <200602211006.46551.russell@coker.com.au> <20060223144038.GA3972@redhat.com> <200602230922.36050.lamont@gurulabs.com> Message-ID: <20060223190157.GA9443@redhat.com> On Thu, Feb 23, 2006 at 09:22:29AM -0700, Lamont R. Peterson wrote: > > du is *supposed* to report disk usage not > > file sizes. > > I think you have that backwards. du shows the total of file sizes. > > Also, how does --apparent-size create an *inaccurate* picture here? I think > you've got that backwards, too. You're forgetting about sparse files, I think. joe From lamont at gurulabs.com Thu Feb 23 19:05:54 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 23 Feb 2006 12:05:54 -0700 Subject: du confusion In-Reply-To: <20060223190157.GA9443@redhat.com> References: <200602211006.46551.russell@coker.com.au> <200602230922.36050.lamont@gurulabs.com> <20060223190157.GA9443@redhat.com> Message-ID: <200602231205.57729.lamont@gurulabs.com> On Thursday 23 February 2006 12:01pm, Joe Orton wrote: > On Thu, Feb 23, 2006 at 09:22:29AM -0700, Lamont R. Peterson wrote: > > > du is *supposed* to report disk usage not > > > file sizes. > > > > I think you have that backwards. du shows the total of file sizes. > > > > Also, how does --apparent-size create an *inaccurate* picture here? I > > think you've got that backwards, too. > > You're forgetting about sparse files, I think. Ah, you are correct; I was forgetting about them. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From russell at coker.com.au Thu Feb 23 21:44:50 2006 From: russell at coker.com.au (Russell Coker) Date: Fri, 24 Feb 2006 08:44:50 +1100 Subject: du confusion In-Reply-To: <200602231835.k1NIZNRr013994@turing-police.cc.vt.edu> References: <200602211006.46551.russell@coker.com.au> <20060223144038.GA3972@redhat.com> <200602231835.k1NIZNRr013994@turing-police.cc.vt.edu> Message-ID: <200602240844.54406.russell@coker.com.au> On Friday 24 February 2006 05:35, Valdis.Kletnieks at vt.edu wrote: > On Thu, 23 Feb 2006 14:40:39 GMT, Joe Orton said: > > That would be really evil, du is *supposed* to report disk usage not > > file sizes. It's always been true that disk usage and file size can > > diverge, that's why du and ls are separate tools. Actually if we added a couple of new options to ls then du could be an alias to ls. > 'du' doesn't report on the space used by the inode either - and on many > filesystems with many small files, the inode is a significant chunk of > the used space.... On most file systems the Inodes are in a table of fixed size which makes them less relevant. However du also doesn't report directory space used on a per-file basis so a file with a long name is regarded as taking no more space than a file with a short name. du on a directory gives the total space used by all files and directories below it. On Friday 24 February 2006 06:01, Joe Orton wrote: > You're forgetting about sparse files, I think. Correct. This doesn't mean we can't solve this SE Linux related issue, just that we need to solve it in a different way. What if we add a new option to du to use the minimum of the apparent size and the reported number of blocks used. If a sparse file on SE Linux has one sparse block then both numbers will be the same. For non-sparse files du would report the size minus the size of xattrs. For sparse files that have more than one sparse block then du would report the space used which includes the xattrs (IE the same thing it does now by default). Thanks for all the comments. If my latest idea is regarded as worthy then I'll write the patch for coreutils. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Fri Feb 24 00:40:59 2006 From: russell at coker.com.au (Russell Coker) Date: Fri, 24 Feb 2006 11:40:59 +1100 Subject: Error sending status request (Operation not permitted) In-Reply-To: References: Message-ID: <200602241141.04699.russell@coker.com.au> On Thursday 26 January 2006 14:51, Bruce Ecroyd wrote: > 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 When running as user_u you should not be creating any files in a directory with label sysadm_home_dir_t. If such file creation was permitted then user_t would be able to subvert sysadm_t. > If I change to strict, enforcing, will this prevent me from su to root? If you login as staff_r:staff_t then you will be able to su to root with administrative privs, otherwise not. This is by design. -- 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 christofer.c.bell at gmail.com Fri Feb 24 10:07:47 2006 From: christofer.c.bell at gmail.com (Christofer C. Bell) Date: Fri, 24 Feb 2006 04:07:47 -0600 Subject: Samba access for public_html. Message-ID: <143f0f6c0602240207t6caf448eqa40c21d7e42f5ca3@mail.gmail.com> I'd like to be able to drag and drop files in ~/public_html on my FC4 machine running the stock targetted policy with Samba. I'm unable to see that public_html even exists when browsing my share, let alone manipulate files. Here's the avc log: type=AVC msg=audit(1140775433.847:9264): avc: denied { getattr } for pid=30827 comm="smbd" name="public_html" dev=md0 ino=8375104 scontext=system_u:system_r:smbd_t tcontext=user_u:object_r:httpd_sys_content_t tclass=dir Is there an boolean that can be set or is this a job for audit2allow? Thank you very much! -- 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 paul at city-fan.org Fri Feb 24 10:17:18 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 24 Feb 2006 10:17:18 +0000 Subject: Samba access for public_html. In-Reply-To: <143f0f6c0602240207t6caf448eqa40c21d7e42f5ca3@mail.gmail.com> References: <143f0f6c0602240207t6caf448eqa40c21d7e42f5ca3@mail.gmail.com> Message-ID: <43FEDD2E.7060102@city-fan.org> Christofer C. Bell wrote: > I'd like to be able to drag and drop files in ~/public_html on my FC4 > machine running the stock targetted policy with Samba. I'm unable to > see that public_html even exists when browsing my share, let alone > manipulate files. Here's the avc log: > > type=AVC msg=audit(1140775433.847:9264): avc: denied { getattr } for > pid=30827 comm="smbd" name="public_html" dev=md0 ino=8375104 > scontext=system_u:system_r:smbd_t > tcontext=user_u:object_r:httpd_sys_content_t tclass=dir > > Is there an boolean that can be set or is this a job for audit2allow? > Thank you very much! Try: $ chcon -R -t public_content_rw_t ~/public_html $ setsebool -P allow_smb_anon_write 1 See: man samba_selinux Paul. From emeric.maschino at jouy.inra.fr Fri Feb 24 13:23:53 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Fri, 24 Feb 2006 14:23:53 +0100 Subject: hid2hci AVCs Message-ID: <1140787433.5088.32.camel@localhost.localdomain> Hi, For quite some time now, I'm getting AVCs similar to this one in my /var/log/audit/audit.log file: type=AVC msg=audit(1140723627.168:7): avc: denied { ioctl } for pid=1866 comm="hid2hci" name="001" dev=tmpfs ino=3178 scontext=system_u:system_r:bluetooth_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1140723627.168:7): arch=c0000032 syscall=1065 success=no exit=13 a0=4 a1=40085511 a2=60000fffffa61954 a3=1001 items=0 pid=1866 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hid2hci" exe="/usr/sbin/hid2hci" type=AVC_PATH msg=audit(1140723627.168:7): path="/dev/bus/usb/001/001" This is on an Itanium system. Is there something I can try to solve this issue? Many thanks, ?meric From emeric.maschino at jouy.inra.fr Fri Feb 24 13:38:34 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Fri, 24 Feb 2006 14:38:34 +0100 Subject: Swap-related AVC Message-ID: <1140788314.5088.39.camel@localhost.localdomain> Hi, With up-to-date Rawhide, I'm getting the following AVC in my /var/log/messages file: Feb 23 20:40:34 zx6000 kernel: audit(1140723618.608:3): avc: denied { write } for pid=1340 comm="swapon" name="blkid.tab" dev=dm-0 ino=6253814 scontext=system_u:system_r:fsadm_t:s0 tcontext=user_u:object_r:etc_t:s0 tclass=file Feb 23 20:40:34 zx6000 kernel: Adding 2031584k swap on /dev/VolGroup00/LogVol01. Priority:-2 extents:1 across:2031584k I don't know exactly when this problem first appears. It should be noted that, contrarily to what's displayed, my swap partition isn't 2GB in size, but 4GB. Is this a general/64-bit specific/ia64 specific issue? Many thanks, ?meric From dwalsh at redhat.com Fri Feb 24 14:53:20 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 24 Feb 2006 09:53:20 -0500 Subject: hid2hci AVCs In-Reply-To: <1140787433.5088.32.camel@localhost.localdomain> References: <1140787433.5088.32.camel@localhost.localdomain> Message-ID: <43FF1DE0.9000301@redhat.com> Emeric Maschino wrote: > Hi, > > For quite some time now, I'm getting AVCs similar to this one in > my /var/log/audit/audit.log file: > > type=AVC msg=audit(1140723627.168:7): avc: denied { ioctl } for > pid=1866 comm="hid2hci" name="001" dev=tmpfs ino=3178 > scontext=system_u:system_r:bluetooth_t:s0 > tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file > type=SYSCALL msg=audit(1140723627.168:7): arch=c0000032 syscall=1065 > success=no > exit=13 a0=4 a1=40085511 a2=60000fffffa61954 a3=1001 items=0 pid=1866 > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > comm="hid2hci" exe="/usr/sbin/hid2hci" > type=AVC_PATH msg=audit(1140723627.168:7): path="/dev/bus/usb/001/001" > > This is on an Itanium system. Is there something I can try to solve this > issue? > > Many thanks, > > I will fix this in policy. > ?meric > > -- > 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 Fri Feb 24 14:54:01 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 24 Feb 2006 09:54:01 -0500 Subject: Swap-related AVC In-Reply-To: <1140788314.5088.39.camel@localhost.localdomain> References: <1140788314.5088.39.camel@localhost.localdomain> Message-ID: <43FF1E09.8030101@redhat.com> Emeric Maschino wrote: > Hi, > > With up-to-date Rawhide, I'm getting the following AVC in > my /var/log/messages file: > > Feb 23 20:40:34 zx6000 kernel: audit(1140723618.608:3): avc: denied > { write } > for pid=1340 comm="swapon" name="blkid.tab" dev=dm-0 ino=6253814 > scontext=system_u:system_r:fsadm_t:s0 tcontext=user_u:object_r:etc_t:s0 > tclass=file > Feb 23 20:40:34 zx6000 kernel: Adding 2031584k swap > on /dev/VolGroup00/LogVol01. Priority:-2 extents:1 across:2031584k > > I don't know exactly when this problem first appears. It should be noted > that, contrarily to what's displayed, my swap partition isn't 2GB in > size, but 4GB. > > Is this a general/64-bit specific/ia64 specific issue? > > The AVC is general. the inird is creating this file with the wrong context. > Many thanks, > > ?meric > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From louisg00 at bellsouth.net Sun Feb 26 04:04:31 2006 From: louisg00 at bellsouth.net (Louis E Garcia II) Date: Sat, 25 Feb 2006 23:04:31 -0500 Subject: FC4 + samba + selinux Message-ID: <1140926671.16142.9.camel@soncomputer> I am setting up an FC4 samba server and can't get my shares accessed. With selinux off samba works normally. I have created a dir: drwxrwsrwx root root system_u:object_r:samba_share_t /data/public The is the error I get: type=AVC msg=audit(1140923608.645:86): avc: denied { search } for pid=3338 comm="smbd" name="/" dev=hda5 ino=2 scontext=root:system_r:smbd_t tcontext=system_u:object_r:default_t tclass=dir type=SYSCALL msg=audit(1140923608.645:86): arch=40000003 syscall=195 success=no exit=-13 a0=88b85f8 a1=bff9aec4 a2=7fbff4 a3=bff9aec4 items=1 pid=3338 auid=500 uid=502 gid=0 euid=502 suid=0 fsuid=502 egid=100 sgid=100 fsgid=100 comm="smbd" exe="/usr/sbin/smbd" type=CWD msg=audit(1140923608.645:86): cwd="/" type=PATH msg=audit(1140923608.645:86): item=0 name="/data/public" flags=1 inode=2 dev=03:05 mode=040755 ouid=0 ogid=0 rdev=00:00 why does smbd_t want access to default_t when the dir is labeled samba_share_t? Does smbd_t have access to samba_share_t by default? Any advise, --Louis From louisg00 at bellsouth.net Sun Feb 26 04:44:21 2006 From: louisg00 at bellsouth.net (Louis E Garcia II) Date: Sat, 25 Feb 2006 23:44:21 -0500 Subject: FC4 + samba + selinux In-Reply-To: <1140926671.16142.9.camel@soncomputer> References: <1140926671.16142.9.camel@soncomputer> Message-ID: <1140929061.17214.3.camel@soncomputer> If public is in a directory lets say /data/samba/public In order for samba to see it, the directories /data and ./samba need samba_share_t? or just ./public? On Sat, 2006-02-25 at 23:04 -0500, Louis E Garcia II wrote: > I am setting up an FC4 samba server and can't get my shares accessed. > With selinux off samba works normally. > > I have created a dir: > drwxrwsrwx root root > system_u:object_r:samba_share_t /data/public > > The is the error I get: > > type=AVC msg=audit(1140923608.645:86): avc: denied { search } for > pid=3338 comm="smbd" name="/" dev=hda5 ino=2 > scontext=root:system_r:smbd_t tcontext=system_u:object_r:default_t > tclass=dir > type=SYSCALL msg=audit(1140923608.645:86): arch=40000003 syscall=195 > success=no exit=-13 a0=88b85f8 a1=bff9aec4 a2=7fbff4 a3=bff9aec4 items=1 > pid=3338 auid=500 uid=502 gid=0 euid=502 suid=0 fsuid=502 egid=100 > sgid=100 fsgid=100 comm="smbd" exe="/usr/sbin/smbd" > type=CWD msg=audit(1140923608.645:86): cwd="/" > type=PATH msg=audit(1140923608.645:86): item=0 name="/data/public" > flags=1 inode=2 dev=03:05 mode=040755 ouid=0 ogid=0 rdev=00:00 > > why does smbd_t want access to default_t when the dir is labeled > samba_share_t? > > Does smbd_t have access to samba_share_t by default? > > Any advise, --Louis > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From eparis at redhat.com Sun Feb 26 15:30:19 2006 From: eparis at redhat.com (Eric Paris) Date: Sun, 26 Feb 2006 10:30:19 -0500 Subject: FC4 + samba + selinux In-Reply-To: <1140926671.16142.9.camel@soncomputer> References: <1140926671.16142.9.camel@soncomputer> Message-ID: <1140967819.464.4.camel@localhost.localdomain> What is / labeled? In order for smbd to even get to /data/samba it has to be able to search on / and /data. Check out 'ls -Zd /' and 'ls - Zd /data' and make sure they are of types smbd can search. My first guess is that / is labeled wrong (I think it sholud be system_u:object_r:root_t) -Eric On Sat, 2006-02-25 at 23:04 -0500, Louis E Garcia II wrote: > I am setting up an FC4 samba server and can't get my shares accessed. > With selinux off samba works normally. > > I have created a dir: > drwxrwsrwx root root > system_u:object_r:samba_share_t /data/public > > The is the error I get: > > type=AVC msg=audit(1140923608.645:86): avc: denied { search } for > pid=3338 comm="smbd" name="/" dev=hda5 ino=2 > scontext=root:system_r:smbd_t tcontext=system_u:object_r:default_t > tclass=dir > type=SYSCALL msg=audit(1140923608.645:86): arch=40000003 syscall=195 > success=no exit=-13 a0=88b85f8 a1=bff9aec4 a2=7fbff4 a3=bff9aec4 items=1 > pid=3338 auid=500 uid=502 gid=0 euid=502 suid=0 fsuid=502 egid=100 > sgid=100 fsgid=100 comm="smbd" exe="/usr/sbin/smbd" > type=CWD msg=audit(1140923608.645:86): cwd="/" > type=PATH msg=audit(1140923608.645:86): item=0 name="/data/public" > flags=1 inode=2 dev=03:05 mode=040755 ouid=0 ogid=0 rdev=00:00 > > why does smbd_t want access to default_t when the dir is labeled > samba_share_t? > > Does smbd_t have access to samba_share_t by default? > > Any advise, --Louis > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From emeric.maschino at jouy.inra.fr Mon Feb 27 10:26:45 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Mon, 27 Feb 2006 11:26:45 +0100 Subject: hid2hci AVCs In-Reply-To: <43FF1DE0.9000301@redhat.com> References: <1140787433.5088.32.camel@localhost.localdomain> <43FF1DE0.9000301@redhat.com> Message-ID: <1141036005.29905.9.camel@localhost.localdomain> Hi, I confirm that these AVCs go away with the saturday updates. Many thanks. Cheers, ?meric Le vendredi 24 f?vrier 2006 ? 09:53 -0500, Daniel J Walsh a ?crit : > Emeric Maschino wrote: > > Hi, > > > > For quite some time now, I'm getting AVCs similar to this one in > > my /var/log/audit/audit.log file: > > > > type=AVC msg=audit(1140723627.168:7): avc: denied { ioctl } for > > pid=1866 comm="hid2hci" name="001" dev=tmpfs ino=3178 > > scontext=system_u:system_r:bluetooth_t:s0 > > tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file > > type=SYSCALL msg=audit(1140723627.168:7): arch=c0000032 syscall=1065 > > success=no > > exit=13 a0=4 a1=40085511 a2=60000fffffa61954 a3=1001 items=0 pid=1866 > > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > > comm="hid2hci" exe="/usr/sbin/hid2hci" > > type=AVC_PATH msg=audit(1140723627.168:7): path="/dev/bus/usb/001/001" > > > > This is on an Itanium system. Is there something I can try to solve this > > issue? > > > > Many thanks, > > > > > I will fix this in policy. > > ?meric > > > > -- > > 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 Feb 27 16:09:30 2006 From: selinux at gmail.com (Tom London) Date: Mon, 27 Feb 2006 08:09:30 -0800 Subject: AVC when configuring printer..... Message-ID: <4c4ba1530602270809v52ea81e8k7ce5b0dc4bbbb10b@mail.gmail.com> Running latest Rawhide, targeted/enforcing. System->Administration->Printing, and hitting 'Apply' on the currently configured printer produces the following: ---- type=PATH msg=audit(02/27/2006 08:04:15.126:101) : item=2 flags=follow,open inode=1045697 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 type=PATH msg=audit(02/27/2006 08:04:15.126:101) : item=1 flags=follow,open inode=5786615 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 type=PATH msg=audit(02/27/2006 08:04:15.126:101) : item=0 name=/usr/sbin/printconf-backend flags=follow,open inode=5790576 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(02/27/2006 08:04:15.126:101) : cwd=/ type=AVC_PATH msg=audit(02/27/2006 08:04:15.126:101) : path=pipe:[21844] type=AVC_PATH msg=audit(02/27/2006 08:04:15.126:101) : path=/root/.rh-fontconfig/.fonts.cache-2 type=SYSCALL msg=audit(02/27/2006 08:04:15.126:101) : arch=i386 syscall=execve success=yes exit=0 a0=899cdc8 a1=899ce18 a2=899cf20 a3=8999d70 items=3 pid=5773 auid=tbl uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=printconf-backe exe=/usr/bin/python type=AVC msg=audit(02/27/2006 08:04:15.126:101) : avc: denied { read } for pid=5773 comm=printconf-backe name=.fonts.cache-2 dev=dm-0 ino=555510 scontext=system_u:system_r:cupsd_config_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file type=AVC msg=audit(02/27/2006 08:04:15.126:101) : avc: denied { write } for pid=5773 comm=printconf-backe name=[21844] dev=pipefs ino=21844 scontext=system_u:system_r:cupsd_config_t:s0 tcontext=system_u:system_r:unconfined_t:s0 tclass=fifo_file ---- tom -- Tom London From dravet at hotmail.com Tue Feb 28 19:13:45 2006 From: dravet at hotmail.com (Jason Dravet) Date: Tue, 28 Feb 2006 13:13:45 -0600 Subject: selinux and tmpfs message Message-ID: When I boot rawhide I see the following selinux messages. Why is tmpfs listed twice? SELinux: initialized (dev dm-0, type ext3), uses xattr -->SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts SELinux: initialized (dev devpts, type devpts), uses transition SIDs SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts -->SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts SELinux: initialized (dev pipefs, type pipefs), uses task SIDs SELinux: initialized (dev sockfs, type sockfs), uses task SIDs SELinux: initialized (dev proc, type proc), uses genfs_contexts SELinux: initialized (dev bdev, type bdev), uses genfs_contexts SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts Thanks, Jason From notting at redhat.com Tue Feb 28 19:15:59 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 28 Feb 2006 14:15:59 -0500 Subject: selinux and tmpfs message In-Reply-To: References: Message-ID: <20060228191559.GD12950@devserv.devel.redhat.com> Jason Dravet (dravet at hotmail.com) said: > When I boot rawhide I see the following selinux messages. Why is tmpfs > listed twice? I'd guess because it's mounted twice, but ICBW. Bill From sds at tycho.nsa.gov Tue Feb 28 19:35:12 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 28 Feb 2006 14:35:12 -0500 Subject: selinux and tmpfs message In-Reply-To: <20060228191559.GD12950@devserv.devel.redhat.com> References: <20060228191559.GD12950@devserv.devel.redhat.com> Message-ID: <1141155312.3904.27.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-02-28 at 14:15 -0500, Bill Nottingham wrote: > Jason Dravet (dravet at hotmail.com) said: > > When I boot rawhide I see the following selinux messages. Why is tmpfs > > listed twice? > > I'd guess because it's mounted twice, but ICBW. Yes, SELinux prints one of these messages for each such mount, and in this case you are likely getting one for the /dev mount and one for the /dev/shm mount. $ grep tmpfs /proc/mounts -- Stephen Smalley National Security Agency From dravet at hotmail.com Tue Feb 28 20:30:24 2006 From: dravet at hotmail.com (Jason Dravet) Date: Tue, 28 Feb 2006 14:30:24 -0600 Subject: selinux and tmpfs message In-Reply-To: <1141155312.3904.27.camel@moss-spartans.epoch.ncsc.mil> Message-ID: >From: Stephen Smalley > > Jason Dravet (dravet at hotmail.com) said: > > > When I boot rawhide I see the following selinux messages. Why is >tmpfs > > > listed twice? > > > > I'd guess because it's mounted twice, but ICBW. > >Yes, SELinux prints one of these messages for each such mount, and in >this case you are likely getting one for the /dev mount and one for >the /dev/shm mount. > >$ grep tmpfs /proc/mounts You are right, the output from grep shows /dev and /dev/shm. I thought it might a bug. Thank you both for the explaination. Jason From kcarr at tresys.com Tue Feb 28 23:01:24 2006 From: kcarr at tresys.com (Kevin Carr) Date: Tue, 28 Feb 2006 18:01:24 -0500 Subject: ANN: SELinux Policy IDE (SLIDE) Message-ID: <200602282301.k1SN1ONq024854@gotham.columbia.tresys.com> The first release of the SELinux Policy IDE (called SLIDE) from Tresys is available for download on the Tresys website. Also, there is a sourceforge project site with screenshots and some documentation. http://tresys.com/selinux/index.shtml http://selinux-ide.sourceforge.net/index.php The tool is an eclipse plug-in that integrates with reference policy and should hopefully be found useful. It is still under development as this is just an initial release. Kevin Carr Tresys Technology 410.290.1411 x137 From kcarr at tresys.com Tue Feb 28 23:16:32 2006 From: kcarr at tresys.com (Kevin Carr) Date: Tue, 28 Feb 2006 18:16:32 -0500 Subject: ANN: CDS Framework IDE Message-ID: <200602282316.k1SNGWNq024943@gotham.columbia.tresys.com> Tresys has completed an initial version of the CDS Framework IDE tool to assist in developing cross domain solutions for SELinux. The tool consists of an IDE with a new high-level language to specify CDS architectures focused on the information flow goals of the particular project. The tool generates the necessary SELinux policy from the higher-level specification. It is available open source on the Tresys Technology website. http://tresys.com/selinux/index.shtml It's is an Eclipse plug-in so just extract the tarball in your plugins directory. Kevin Carr Tresys Technology 410.290.1411 x137