On Jan 5, 2012, at 4:46 PM, Daniel J Walsh wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 01/05/2012 04:36 PM, Bennett Haselton wrote:

...

http://wiki.centos.org/HowTos/SELinux says: "Access is only allowed between similar types, so Apache running as httpd_t can read /var/www/html/index.html of type httpd_sys_content_t."

however the doc doesn't define what "similar types" means. I assumed it just meant "beginning with the same prefix". However that can't be right because on my system with SELinux turned on, httpd runs as type init_t:

[root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3 system_u:system_r:init_t:s0 root 2521 0.1 0.4 21680 8820 ? Ss 05:05 0:00 /usr/sbin/httpd system_u:system_r:init_t:s0 apache 2550 0.0 0.4 23364 8920 ? S 05:05 0:00 /usr/sbin/httpd system_u:system_r:init_t:s0 apache 2551 0.1 0.4 22736 8212 ? S 05:05 0:00 /usr/sbin/httpd

and the robots.txt file has type file_t: [root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root system_u:object_r:file_t:s0 /var/www/html/robots.txt

but Apache can of course access that file. So in Type Enforcement, what determines what process type can access what file type?

Bennett _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Your machine needs to be relabeled.

touch /.autorelabel reboot

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8GGk4ACgkQrlYvE4MpobMVkgCfVagwQqbzB2UW1+TEsrrCVhF5 lFkAnjLTi3zphekGomv04ZyMu0sOuopg =cIvM -----END PGP SIGNATURE----- _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

WARNING: If you have never enabled SELinux for long time, the boot is going to take a while as the system relabels the whole machine. Do not do this unless you can plan for an extend downtime.

On 1/5/2012 4:37 PM, Bennett Haselton wrote:

On 1/5/2012 3:14 PM, RILINDO FOSTER wrote:

...

On Jan 5, 2012, at 4:46 PM, Daniel J Walsh wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 01/05/2012 04:36 PM, Bennett Haselton wrote:

...

http://wiki.centos.org/HowTos/SELinux says: "Access is only allowed between similar types, so Apache running as httpd_t can read /var/www/html/index.html of type httpd_sys_content_t."

however the doc doesn't define what "similar types" means. I assumed it just meant "beginning with the same prefix". However that can't be right because on my system with SELinux turned on, httpd runs as type init_t:

[root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3 system_u:system_r:init_t:s0 root 2521 0.1 0.4 21680 8820 ? Ss 05:05 0:00 /usr/sbin/httpd system_u:system_r:init_t:s0 apache 2550 0.0 0.4 23364 8920 ? S 05:05 0:00 /usr/sbin/httpd system_u:system_r:init_t:s0 apache 2551 0.1 0.4 22736 8212 ? S 05:05 0:00 /usr/sbin/httpd

and the robots.txt file has type file_t: [root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root system_u:object_r:file_t:s0 /var/www/html/robots.txt

but Apache can of course access that file. So in Type Enforcement, what determines what process type can access what file type?

Bennett _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Your machine needs to be relabeled.

touch /.autorelabel reboot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8GGk4ACgkQrlYvE4MpobMVkgCfVagwQqbzB2UW1+TEsrrCVhF5 lFkAnjLTi3zphekGomv04ZyMu0sOuopg =cIvM -----END PGP SIGNATURE----- _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

WARNING: If you have never enabled SELinux for long time, the boot is going to take a while as the system relabels the whole machine. Do not do this unless you can plan for an extend downtime.

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

I did do touch /.autorelabel reboot

The machine booted back up in just a few minutes, what looked like normal reboot time. And then I ran the same commands as before and got what looks to me like the same output:

[root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root system_u:object_r:file_t:s0 /var/www/html/robots.txt [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3 system_u:system_r:init_t:s0 root 2530 0.0 0.4 21680 8820 ? Ss 16:23 0:00 /usr/sbin/httpd system_u:system_r:init_t:s0 apache 2558 0.8 0.8 28308 16392 ? S 16:23 0:03 /usr/sbin/httpd system_u:system_r:init_t:s0 apache 2560 0.5 0.5 23248 10236 ? S 16:23 0:02 /usr/sbin/httpd

So I'm wondering:

1. How did you know that the machine needed to be relabeled, was it

something in the output of the commands the first time I ran them? and in that case, 2) Why didn't it change after I created /.autorelabel and rebooted? (I can confirm the file /.autorelabel is no longer present, so it must have been deleted when the auto-relabel was done, like the doc says.) 3) If the machine booted back up very quickly, should I be worried that the autorelabel might not have happened? Any idea if it logs a message somewhere if it fails to start properly?

OK, I know why Daniel and Rilindo were telling me to relabel -- according to http://fedoraproject.org/wiki/SELinux/Troubleshooting/AVCDecisions and other sources, if a file is listed as type "file_t", it means the system needs to be relabeled.

So I still don't know: after creating /.autorelabel (and verifying that it's there), and rebooting the system (and then verifying that the /.autorelabel file has been deleted, which is supposed to mean the auto-relabel actually happened), why am I still seeing the file type listed as file_t?

Bennett

On 1/7/2012 6:25 PM, Gordon Messmer wrote:

On 01/06/2012 01:36 AM, Bennett Haselton wrote:

...

So I still don't know: after creating /.autorelabel (and verifying that it's there), and rebooting the system (and then verifying that the /.autorelabel file has been deleted, which is supposed to mean the auto-relabel actually happened), why am I still seeing the file type listed as file_t?

Either SELinux is disabled or your filesystem doesn't support extended attributes.

[root@g6950-21025 ~]# sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: permissive Policy version: 21 Policy from config file: targeted

(same thing happens if I switch to "enforcing", although then things start breaking instead of logging warnings)

Check /proc/cmdline to see if the kernel was instructed to disable SELinux

[root@g6950-21025 ~]# cat /proc/cmdline ro root=/dev/sys-0n1f/root

Not sure what that means but I assume it doesn't force SELinux to be disabled.

and check /etc/sysconfig/selinux.

[root@g6950-21025 ~]# cat /etc/sysconfig/selinux # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=permissive # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted [root@g6950-21025 ~]#

Note: SELinux is logging warnings (while in permissive mode) to /var/log/audit/audit.log whenever httpd interacts with one of the files like /tmp/hostname_SKYSLICE.INFO . Presumably that means it's not disabled; SELinux is on, but the file still hasn't been relabeled.

Check /proc/mounts to see what filesystem type your system is using.

[root@g6950-21025 ~]# cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext3 rw,data=ordered 0 0 /dev /dev tmpfs rw 0 0 /proc /proc proc rw 0 0 /sys /sys sysfs rw 0 0 none /selinux selinuxfs rw 0 0 /proc/bus/usb /proc/bus/usb usbfs rw 0 0 devpts /dev/pts devpts rw 0 0 /dev/sys-0n1f/vartmp /var/tmp ext3 rw,nosuid,noexec,data=ordered 0 0 /dev/sys-0n1f/tmp /tmp ext3 rw,nosuid,noexec,data=ordered 0 0 /dev/sda1 /boot ext3 rw,data=ordered 0 0 tmpfs /dev/shm tmpfs rw,nosuid,noexec 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 /etc/auto.misc /misc autofs rw,fd=7,pgrp=2217,timeout=300,minproto=5,maxproto=5,indirect 0 0 -hosts /net autofs rw,fd=13,pgrp=2217,timeout=300,minproto=5,maxproto=5,indirect 0 0

Use "tune2fs -l" to see if an ext3/4 filesystem has the "user_xattr" option. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

In the output above, /dev/root /dev/sys-0n1f/vartmp /dev/sys-0n1f/tmp /dev/sda1

were all listed as ext3, and when I ran "tune2fs -l" on each of them, the output included the line Default mount options: user_xattr acl

Bennett

On 1/6/2012 5:58 AM, RILINDO FOSTER wrote:

On Jan 5, 2012, at 7:37 PM, Bennett Haselton wrote:

...

On 1/5/2012 3:14 PM, RILINDO FOSTER wrote:

...

On Jan 5, 2012, at 4:46 PM, Daniel J Walsh wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 01/05/2012 04:36 PM, Bennett Haselton wrote:

...

http://wiki.centos.org/HowTos/SELinux says: "Access is only allowed between similar types, so Apache running as httpd_t can read /var/www/html/index.html of type httpd_sys_content_t."

however the doc doesn't define what "similar types" means. I assumed it just meant "beginning with the same prefix". However that can't be right because on my system with SELinux turned on, httpd runs as type init_t:

[root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3 system_u:system_r:init_t:s0 root 2521 0.1 0.4 21680 8820 ? Ss 05:05 0:00 /usr/sbin/httpd system_u:system_r:init_t:s0 apache 2550 0.0 0.4 23364 8920 ? S 05:05 0:00 /usr/sbin/httpd system_u:system_r:init_t:s0 apache 2551 0.1 0.4 22736 8212 ? S 05:05 0:00 /usr/sbin/httpd

and the robots.txt file has type file_t: [root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root system_u:object_r:file_t:s0 /var/www/html/robots.txt

but Apache can of course access that file. So in Type Enforcement, what determines what process type can access what file type?

Bennett _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Your machine needs to be relabeled.

touch /.autorelabel reboot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8GGk4ACgkQrlYvE4MpobMVkgCfVagwQqbzB2UW1+TEsrrCVhF5 lFkAnjLTi3zphekGomv04ZyMu0sOuopg =cIvM -----END PGP SIGNATURE----- _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

WARNING: If you have never enabled SELinux for long time, the boot is going to take a while as the system relabels the whole machine. Do not do this unless you can plan for an extend downtime.

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

I did do touch /.autorelabel reboot

The machine booted back up in just a few minutes, what looked like normal reboot time. And then I ran the same commands as before and got what looks to me like the same output:

[root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root system_u:object_r:file_t:s0 /var/www/html/robots.txt [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3 system_u:system_r:init_t:s0 root 2530 0.0 0.4 21680 8820 ? Ss 16:23 0:00 /usr/sbin/httpd system_u:system_r:init_t:s0 apache 2558 0.8 0.8 28308 16392 ? S 16:23 0:03 /usr/sbin/httpd system_u:system_r:init_t:s0 apache 2560 0.5 0.5 23248 10236 ? S 16:23 0:02 /usr/sbin/httpd

So I'm wondering:

1. How did you know that the machine needed to be relabeled, was it

something in the output of the commands the first time I ran them? and in that case, 2) Why didn't it change after I created /.autorelabel and rebooted? (I can confirm the file /.autorelabel is no longer present, so it must have been deleted when the auto-relabel was done, like the doc says.) 3) If the machine booted back up very quickly, should I be worried that the autorelabel might not have happened? Any idea if it logs a message somewhere if it fails to start properly? _______________________________________________

That sort of sound like a good thing. I would suggest that you do:

tail -f /var/log/audit/audit.log | audit2allow

To see what type of alerts you are getting. Likely you will get a lot, as some of the file contexts may not be labeled correctly.

I did that but it produces descriptions all beginning with

"Summary:

SELinux is preventing access to files with the label, file_t."

In other words, it's describing errors that are the result of the relabeling failure, but it doesn't appear to say anything about what *caused* the relabeling failure (or if it does it's buried in so many other errors I don't know how to find it).

Bennett

Le ven 06 jan 2012 02:00:27 CET, Bennett Haselton a écrit:

On 1/5/2012 1:36 PM, Bennett Haselton wrote: ... OK, notwithstanding the fact that the filesystem on the above machine needs to be re-labeled and I don't know why that's failing --

I have another CentOS 5.7 machine where I've enabled SELinux (permissive mode) and relabeled the filesystem and it actually worked, so that the above commands are now giving the expected outputs:

[root@g6950-21025 ~]# ps awuxZ | grep httpd | head -n 3 system_u:system_r:init_t root 2302 0.0 1.0 253056 10576 ? Ss 00:12 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 4201 0.1 2.0 274804 20968 ? S 01:26 0:02 /usr/sbin/httpd system_u:system_r:init_t apache 4392 0.2 1.2 257308 12512 ? S 01:39 0:01 /usr/sbin/httpd

Apache running as "init_t" is a call for troubles. $ ps awuxZ | grep [a]pache system_u:system_r:httpd_t apache ... /usr/sbin/httpd

[root@g6950-21025 ~]# ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root system_u:object_r:httpd_sys_content_t /var/www/html/robots.txt

This is correct.

Le ven 06 jan 2012 02:41:02 CET, Bennett Haselton a écrit:

On 1/6/2012 2:24 AM, Philippe Naudin wrote:

...

Apache running as "init_t" is a call for troubles.

Is it? OK, any idea what caused that and how to fix it?

No, sorry. Your httpd comes from CentOS ?

Afaik, you should not have any process running in context init_t except init itself. If "ps awuxZ | grep [i]nit_t" returns more than only init and httpd, your problem is likely to be more complicated than a broken configuration of apache.

If only httpd is concerned, check "ls -Z /usr/sbin/httpd" : -rwxr-xr-x root root system_u:object_r:httpd_exec_t /usr/sbin/httpd and try eventually "yum reinstall httpd" ...

Le ven 06 jan 2012 04:21:14 CET, Bennett Haselton a écrit:

On 1/6/2012 4:11 AM, Philippe Naudin wrote:

...

Le ven 06 jan 2012 02:41:02 CET, Bennett Haselton a écrit:

...

On 1/6/2012 2:24 AM, Philippe Naudin wrote:

...

Apache running as "init_t" is a call for troubles.

Is it? OK, any idea what caused that and how to fix it?

No, sorry. Your httpd comes from CentOS ?

Yes

...

Afaik, you should not have any process running in context init_t except init itself. If "ps awuxZ | grep [i]nit_t" returns more than only init and httpd, your problem is likely to be more complicated than a broken configuration of apache.

I've got a few...

[root@g6950-21025 ~]# ps auwxZ | grep init_t system_u:system_r:init_t root 1 0.6 0.0 10368 712 ? Ss 04:17 0:00 init [3]

system_u:system_r:init_t root 537 0.2 0.1 13728 1976 ? S<s 04:17 0:00 /sbin/udevd -d system_u:system_r:init_t root 1684 0.0 0.0 38880 456 ? Ssl 04:18 0:00 brcm_iscsiuio system_u:system_r:init_t root 1690 0.0 0.0 12152 476 ? Ss 04:18 0:00 iscsid system_u:system_r:init_t root 1691 0.0 0.4 12648 4460 ? S<Ls 04:18 0:00 iscsid system_u:system_r:init_t dbus 2081 0.0 0.1 31520 1144 ? Ssl 04:18 0:00 dbus-daemon --system system_u:system_r:init_t root 2215 0.0 0.1 52372 1492 ? Ssl 04:18 0:00 automount system_u:system_r:init_t root 2254 0.0 0.1 62656 1212 ? Ss 04:18 0:00 /usr/sbin/sshd system_u:system_r:init_t ntp 2273 0.0 0.4 23412 5044 ? SLs 04:18 0:00 ntpd -u ntp:ntp -p /var /run/ntpd.pid -g system_u:system_r:init_t root 2287 0.1 1.0 253312 10580 ? Ss 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2315 0.3 1.3 259488 13376 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2316 0.0 1.0 257436 11124 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2317 0.1 1.1 257436 11288 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2318 0.1 1.1 257436 11292 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2319 0.0 1.0 256720 10504 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2320 0.1 1.0 257436 10752 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2321 0.0 1.1 257436 11272 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2322 0.1 1.1 257436 11356 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t root 2386 0.0 0.0 3812 492 tty1 Ss+ 04:18 0:00 /sbin/mingetty tty1 system_u:system_r:init_t root 2387 0.0 0.0 3812 488 tty2 Ss+ 04:18 0:00 /sbin/mingetty tty2 system_u:system_r:init_t root 2390 0.0 0.0 3812 488 tty3 Ss+ 04:18 0:00 /sbin/mingetty tty3 system_u:system_r:init_t root 2392 0.0 0.0 3812 492 tty4 Ss+ 04:18 0:00 /sbin/mingetty tty4 system_u:system_r:init_t root 2394 0.0 0.0 3812 488 tty5 Ss+ 04:18 0:00 /sbin/mingetty tty5 system_u:system_r:init_t root 2397 0.0 0.0 3812 488 tty6 Ss+ 04:18 0:00 /sbin/mingetty tty6 system_u:system_r:init_t apache 2405 0.1 1.0 256412 11008 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t root 2406 0.3 0.3 90156 3456 ? Ss 04:18 0:00 sshd: root@pts/0 root:system_r:initrc_t:SystemLow-SystemHigh root 2458 0.0 0.0 61176 768 pts/0 S+ 04:18 0:00 grep init_t

I also found at least one file (the audit.log file) which has file type file_t, even though I thought the filesystem had been re-labeled successfully because /var/www/html/robots.txt had the correct type:

[root@g6950-21025 ~]# ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root system_u:object_r:httpd_sys_content_t /var/www/html/robots.txt [root@g6950-21025 ~]# ls -lZ /var/log/audit/audit.log -rw------- root root system_u:object_r:file_t /var/log/audit/audit.log

Any idea (1) what could be causing that and (2) whether it could be related to the problem with all those init_t processes?

It's easy : your init process is broken, all these daemons but init are mis-labeled, so all the files they create (such as log files) are mis-labeled.

And if the next question is "how to fix it ?", the answer is easy too : "I don't have any clue..."

Sorry,

On 1/6/2012 5:55 AM, RILINDO FOSTER wrote:

On Jan 6, 2012, at 7:40 AM, Philippe Naudin wrote:

...

Le ven 06 jan 2012 04:21:14 CET, Bennett Haselton a écrit:

...

On 1/6/2012 4:11 AM, Philippe Naudin wrote:

...

Le ven 06 jan 2012 02:41:02 CET, Bennett Haselton a écrit:

...

On 1/6/2012 2:24 AM, Philippe Naudin wrote:

...

Apache running as "init_t" is a call for troubles.

Is it? OK, any idea what caused that and how to fix it?

No, sorry. Your httpd comes from CentOS ?

Yes

...

Afaik, you should not have any process running in context init_t except init itself. If "ps awuxZ | grep [i]nit_t" returns more than only init and httpd, your problem is likely to be more complicated than a broken configuration of apache.

I've got a few...

[root@g6950-21025 ~]# ps auwxZ | grep init_t system_u:system_r:init_t root 1 0.6 0.0 10368 712 ? Ss 04:17 0:00 init [3]

system_u:system_r:init_t root 537 0.2 0.1 13728 1976 ? S<s 04:17 0:00 /sbin/udevd -d system_u:system_r:init_t root 1684 0.0 0.0 38880 456 ? Ssl 04:18 0:00 brcm_iscsiuio system_u:system_r:init_t root 1690 0.0 0.0 12152 476 ? Ss 04:18 0:00 iscsid system_u:system_r:init_t root 1691 0.0 0.4 12648 4460 ? S<Ls 04:18 0:00 iscsid system_u:system_r:init_t dbus 2081 0.0 0.1 31520 1144 ? Ssl 04:18 0:00 dbus-daemon --system system_u:system_r:init_t root 2215 0.0 0.1 52372 1492 ? Ssl 04:18 0:00 automount system_u:system_r:init_t root 2254 0.0 0.1 62656 1212 ? Ss 04:18 0:00 /usr/sbin/sshd system_u:system_r:init_t ntp 2273 0.0 0.4 23412 5044 ? SLs 04:18 0:00 ntpd -u ntp:ntp -p /var /run/ntpd.pid -g system_u:system_r:init_t root 2287 0.1 1.0 253312 10580 ? Ss 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2315 0.3 1.3 259488 13376 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2316 0.0 1.0 257436 11124 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2317 0.1 1.1 257436 11288 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2318 0.1 1.1 257436 11292 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2319 0.0 1.0 256720 10504 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2320 0.1 1.0 257436 10752 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2321 0.0 1.1 257436 11272 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2322 0.1 1.1 257436 11356 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t root 2386 0.0 0.0 3812 492 tty1 Ss+ 04:18 0:00 /sbin/mingetty tty1 system_u:system_r:init_t root 2387 0.0 0.0 3812 488 tty2 Ss+ 04:18 0:00 /sbin/mingetty tty2 system_u:system_r:init_t root 2390 0.0 0.0 3812 488 tty3 Ss+ 04:18 0:00 /sbin/mingetty tty3 system_u:system_r:init_t root 2392 0.0 0.0 3812 492 tty4 Ss+ 04:18 0:00 /sbin/mingetty tty4 system_u:system_r:init_t root 2394 0.0 0.0 3812 488 tty5 Ss+ 04:18 0:00 /sbin/mingetty tty5 system_u:system_r:init_t root 2397 0.0 0.0 3812 488 tty6 Ss+ 04:18 0:00 /sbin/mingetty tty6 system_u:system_r:init_t apache 2405 0.1 1.0 256412 11008 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t root 2406 0.3 0.3 90156 3456 ? Ss 04:18 0:00 sshd: root@pts/0 root:system_r:initrc_t:SystemLow-SystemHigh root 2458 0.0 0.0 61176 768 pts/0 S+ 04:18 0:00 grep init_t

I also found at least one file (the audit.log file) which has file type file_t, even though I thought the filesystem had been re-labeled successfully because /var/www/html/robots.txt had the correct type:

[root@g6950-21025 ~]# ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root system_u:object_r:httpd_sys_content_t /var/www/html/robots.txt [root@g6950-21025 ~]# ls -lZ /var/log/audit/audit.log -rw------- root root system_u:object_r:file_t /var/log/audit/audit.log

Any idea (1) what could be causing that and (2) whether it could be related to the problem with all those init_t processes?

It's easy : your init process is broken, all these daemons but init are mis-labeled, so all the files they create (such as log files) are mis-labeled.

And if the next question is "how to fix it ?", the answer is easy too : "I don't have any clue..."

Assuming that httpd came from CentOS, it should be appropriate relabeled. If not, using the semanage -f context would fix it.

Are you talking about changing the security context on the /usr/sbin/httpd file itself? What should it be set to? Right now it's [root@g6950-21025 ~]# ls -lZ /usr/sbin/httpd -rwxr-xr-x root root system_u:object_r:file_t /usr/sbin/httpd

This requires some thought. I'll respond back later.

Thanks!

On 1/6/2012 7:13 AM, Daniel J Walsh wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 01/06/2012 09:57 AM, Bennett Haselton wrote:

...

On 1/6/2012 5:55 AM, RILINDO FOSTER wrote:

...

On Jan 6, 2012, at 7:40 AM, Philippe Naudin wrote:

...

Le ven 06 jan 2012 04:21:14 CET, Bennett Haselton a écrit:

...

On 1/6/2012 4:11 AM, Philippe Naudin wrote:

...

Le ven 06 jan 2012 02:41:02 CET, Bennett Haselton a écrit:

> On 1/6/2012 2:24 AM, Philippe Naudin wrote: >> Apache running as "init_t" is a call for troubles. > Is it? OK, any idea what caused that and how to fix it? No, sorry. Your httpd comes from CentOS ?

Yes

...

Afaik, you should not have any process running in context init_t except init itself. If "ps awuxZ | grep [i]nit_t" returns more than only init and httpd, your problem is likely to be more complicated than a broken configuration of apache.

I've got a few...

[root@g6950-21025 ~]# ps auwxZ | grep init_t system_u:system_r:init_t root 1 0.6 0.0 10368 712 ? Ss 04:17 0:00 init [3]

system_u:system_r:init_t root 537 0.2 0.1 13728 1976 ? S<s 04:17 0:00 /sbin/udevd -d system_u:system_r:init_t root 1684 0.0 0.0 38880 456 ? Ssl 04:18 0:00 brcm_iscsiuio system_u:system_r:init_t root 1690 0.0 0.0 12152 476 ? Ss 04:18 0:00 iscsid system_u:system_r:init_t root 1691 0.0 0.4 12648 4460 ? S<Ls 04:18 0:00 iscsid system_u:system_r:init_t dbus 2081 0.0 0.1 31520 1144 ? Ssl 04:18 0:00 dbus-daemon --system system_u:system_r:init_t root 2215 0.0 0.1 52372 1492 ? Ssl 04:18 0:00 automount system_u:system_r:init_t root 2254 0.0 0.1 62656 1212 ? Ss 04:18 0:00 /usr/sbin/sshd system_u:system_r:init_t ntp 2273 0.0 0.4 23412 5044 ? SLs 04:18 0:00 ntpd -u ntp:ntp -p /var /run/ntpd.pid -g system_u:system_r:init_t root 2287 0.1 1.0 253312 10580 ? Ss 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2315 0.3 1.3 259488 13376 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2316 0.0 1.0 257436 11124 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2317 0.1 1.1 257436 11288 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2318 0.1 1.1 257436 11292 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2319 0.0 1.0 256720 10504 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2320 0.1 1.0 257436 10752 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2321 0.0 1.1 257436 11272 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t apache 2322 0.1 1.1 257436 11356 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t root 2386 0.0 0.0 3812 492 tty1 Ss+ 04:18 0:00 /sbin/mingetty tty1 system_u:system_r:init_t root 2387 0.0 0.0 3812 488 tty2 Ss+ 04:18 0:00 /sbin/mingetty tty2 system_u:system_r:init_t root 2390 0.0 0.0 3812 488 tty3 Ss+ 04:18 0:00 /sbin/mingetty tty3 system_u:system_r:init_t root 2392 0.0 0.0 3812 492 tty4 Ss+ 04:18 0:00 /sbin/mingetty tty4 system_u:system_r:init_t root 2394 0.0 0.0 3812 488 tty5 Ss+ 04:18 0:00 /sbin/mingetty tty5 system_u:system_r:init_t root 2397 0.0 0.0 3812 488 tty6 Ss+ 04:18 0:00 /sbin/mingetty tty6 system_u:system_r:init_t apache 2405 0.1 1.0 256412 11008 ? S 04:18 0:00 /usr/sbin/httpd system_u:system_r:init_t root 2406 0.3 0.3 90156 3456 ? Ss 04:18 0:00 sshd: root@pts/0 root:system_r:initrc_t:SystemLow-SystemHigh root 2458 0.0 0.0 61176 768 pts/0 S+ 04:18 0:00 grep init_t

I also found at least one file (the audit.log file) which has file type file_t, even though I thought the filesystem had been re-labeled successfully because /var/www/html/robots.txt had the correct type:

[root@g6950-21025 ~]# ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root system_u:object_r:httpd_sys_content_t /var/www/html/robots.txt [root@g6950-21025 ~]# ls -lZ /var/log/audit/audit.log -rw------- root root system_u:object_r:file_t /var/log/audit/audit.log

Any idea (1) what could be causing that and (2) whether it could be related to the problem with all those init_t processes?

It's easy : your init process is broken, all these daemons but init are mis-labeled, so all the files they create (such as log files) are mis-labeled.

And if the next question is "how to fix it ?", the answer is easy too : "I don't have any clue..."

Assuming that httpd came from CentOS, it should be appropriate relabeled. If not, using the semanage -f context would fix it.

Are you talking about changing the security context on the /usr/sbin/httpd file itself? What should it be set to? Right now it's [root@g6950-21025 ~]# ls -lZ /usr/sbin/httpd -rwxr-xr-x root root system_u:object_r:file_t /usr/sbin/httpd

...

This requires some thought. I'll respond back later.

Thanks! _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

What does

restorecon -R -v /usr/sbin

Say?

I ran that with the additional "-n" flag so it would just tell me what it *would* change (without actually changing anything) and it listed almost all the files in there (including httpd).

But then I tried something else first, the page at http://wiki.centos.org/HowTos/SELinux says that "if the system has been upgraded to CentOS-5.2 with SELinux disabled, and SELinux is then enabled", then the relabel will fail, and you have to run these three commands:

# genhomedircon # touch /.autorelabel # reboot

I tried that and it worked -- the httpd processes are now listed with "httpd_t" as their context, the /var/log/audit/audit.log file is listed with auditd_log_t as its type instead if file_t, etc.

I'm pretty sure this machine was never "upgraded to CentOS 5.2", it was just imaged with 5.7 when the hosting company set it up, but SELinux *was* off until I turned it on. So probably the doc should say, if the "system was *installed* with 5.2, then do this" (and presumably it's 5.2 or later, not just 5.2).

If this changes the label, then execute

fixfiles restore

Which should relabel the system.

If restorecon does nothing or prints error messages,

What file system are you using? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8HD6EACgkQrlYvE4MpobNGOwCgl9VK72f8XQbQVhL7IPHu5J6l kE4AoLBVPrjUduuboqfdgnNfEkrwMi2m =//xT -----END PGP SIGNATURE-----

On 1/6/2012 6:16 PM, RILINDO FOSTER wrote:

On Jan 6, 2012, at 10:35 AM, Bennett Haselton wrote:

...

I tried that and it worked -- the httpd processes are now listed with "httpd_t" as their context, the /var/log/audit/audit.log file is listed with auditd_log_t as its type instead if file_t, etc.

I'm pretty sure this machine was never "upgraded to CentOS 5.2", it was just imaged with 5.7 when the hosting company set it up, but SELinux *was* off until I turned it on. So probably the doc should say, if the "system was *installed* with 5.2, then do this" (and presumably it's 5.2 or later, not just 5.2).

Either that, or the base install was an earlier version of Centos 5.x, with SELinux turned off then upgraded to the current version.

• Rilindo

Could be in theory but if the hosting company was provisioning a new machine I don't know why they'd set up an earlier version and then upgrade, instead of just imaging the latest version at the time.

As for the original question -- when the docs say that access is allowed only across "similar types", what determines what counts as "similar types"? How do you know for example that httpd running as type httpd_t can access /var/www/html/robots.txt which has type httpd_sys_content_t?

Bennett

On 1/7/2012 4:16 AM, Marko Vojinovic wrote:

On Friday 06 January 2012 18:27:05 Bennett Haselton wrote:

...

On 1/6/2012 6:16 PM, RILINDO FOSTER wrote:

...

On Jan 6, 2012, at 10:35 AM, Bennett Haselton wrote:

...

I'm pretty sure this machine was never "upgraded to CentOS 5.2", it was just imaged with 5.7 when the hosting company set it up, but SELinux *was* off until I turned it on. So probably the doc should say, if the "system was *installed* with 5.2, then do this" (and presumably it's 5.2 or later, not just 5.2).

Either that, or the base install was an earlier version of Centos 5.x, with SELinux turned off then upgraded to the current version.>

Could be in theory but if the hosting company was provisioning a new machine I don't know why they'd set up an earlier version and then upgrade, instead of just imaging the latest version at the time.

How about --- the hosting company installs CentOS once (the 5.2 version) as their master image, turns off SELinux, and keeps updating the image over time? And when a customer asks for a new machine, they just make a copy of the current state of the master image? I guess that would be much easier (for them), compared to actually installing the latest version of CentOS from scratch, for every customer.

Why don't you ask the hosting company exactly what kind of system did they provide to you? Since SELinux was off by default, it certainly is not just a default installation of CentOS 5.7 (nor any other version of CentOS). They obviously made some manual after-install customizations before they handed you the system.

IMHO, if a hosting company does that sort of things (especially turning off SELinux), I wouldn't touch them with a ten-foot pole. Who knows what else they might have customized, in their infinite wisdom... :-)

Care to share the name of that hosting company?

Virtually every hosting company I've ever bought a CentOS server from has had SELinux turned off by default. (So, a partial list would include FDCServers, Superb.net, SiteGenie, SecuredServers (ho, ho), AeroVPS (sells dedicated servers despite their name), Netelligent, ServerBeach and I don't remember all the others). Don't hold me to that list 100% since some might have changed their policies for new servers but it's pretty universal.

What hosting company sells sub-$100 unmanaged CentOS dedicated servers and *doesn't* have SELinux turned off?

...

As for the original question -- when the docs say that access is allowed only across "similar types", what determines what counts as "similar types"? How do you know for example that httpd running as type httpd_t can access /var/www/html/robots.txt which has type httpd_sys_content_t?

AFAIK, the interactions between various labels (ie. rules "who can access what") are determined by the SELinux targeted policy (the selinux-policy- targeted package). These rules evolve over time (the package sometimes gets updated and your filesystem autorelabeled to match), and IIRC they can get pretty complicated. You want to look inside that package to find all the rules.

OK. Is it easy to "look inside the package" and where would I look?

But in usual circumstances you shouldn't need to know any details, just let the system label the files as they are supposed to be labeled, and everything should Just Work (tm). If you need to customize something, you can use semanage&restorecon to override the default policy.

HTH, :-) Marko

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On 1/7/2012 5:25 AM, John R. Dennison wrote:

On Sat, Jan 07, 2012 at 04:43:31AM -0800, Bennett Haselton wrote:

...

Virtually every hosting company I've ever bought a CentOS server from has had SELinux turned off by default. (So, a partial list would include FDCServers, Superb.net, SiteGenie, SecuredServers (ho, ho), AeroVPS (sells dedicated servers despite their name), Netelligent, ServerBeach and I don't remember all the others). Don't hold me to that list 100% since some might have changed their policies for new servers but it's pretty universal.

Then these companies should be universally boycotted as it's pretty evident that they don't place security at the top of the importance stack.

People that don't run selinux deserve _everything_ they get and then some.

I remember the same attitude around 2000 and earlier, towards people who spread viruses on Windows. The attitude was that people "should" just learn about their OS (in particular, what types of actions were likely to get you infected), and it wasn't anyone else's "responsibility" to work around it. And the problem kept getting worse.

Then there seemed to be a sea change in attitudes toward the problem -- the realization that complaining about human nature was not going to do any good, and if the marketplace favored selling machines to people who were not highly computer-literate, it was going to happen. Making value judgments about what people "should" and "should not" do, did about as much good as complaining about the sun coming up in the morning.

So an effort was made to change *default* behaviors so that computers would not do bone-headed things even in the hands of bone-headed users. Email servers started scanning for viruses, email programs started giving more and scarier warnings about opening executable attachments, ISPs started bundling anti-virus software, etc. (All of these things were already on the rise, of course.)

And that rolled the problem back a bit. Not complaining about what people "should" know, which never had a chance of working, but changing default behaviors to take into account the fact that most people did not know what the gurus think everyone "should" know. (Of course attackers didn't go away, but switched to trickier methods like browser exploits, which will work even on sophisticated users.)

What you think people "should" know is a matter of opinion. However, complaining about what people "should" know, usually doesn't do any good, and that's an empirical fact, not an opinion.

Apparently the marketplace favors hosting companies turning SELinux off because the failures it causes are too obscure and it causes too many support headaches. A non-changing-human-nature solution might be to notify the user directly when SELinux blocks something. The GUI apparently already does this via a dialog box when viewing a desktop; perhaps there's a way to do it on the command line too. (When the user runs something that's blocked by SELinux, just send a message to the terminal saying "SELinux blocked this", or something. Would be a start.)

By the way, please learn how to properly respond to a public mailing list by trimming unnecessary response content.

Nobody else was trimming. When in Rome :) (By definition, a quoted-quoted-quoted message can only keep getting longer if nobody else is trimming either.)

Bennett

On Sat, Jan 7, 2012 at 8:19 AM, John R. Dennison jrd@gerdesas.com wrote:

I'm truly sick of the "*cry* selinux makes things _hard_ *cry*" whining from not only users but hosting providers and alleged "administrators" that are, at the root of it, too lazy to figure out how to properly use selinux and similar technologies.

To be fair, it was true for years. Mostly the packaging has been fixed so it usually works now if you don't change too much. But don't forget that there is some justification for end users making this complaint. Selinux is really a second layer of defense that should really only come into play because programming correctly is 'too hard' for the developers. But, look at the changelogs and the history of vulnerabilities and you'll realize that part isn't likely to ever change.

On Sat, Jan 07, 2012 at 09:09:45AM -0800, Bennett Haselton wrote:

OK, I followed the instructions at http://wiki.centos.org/HowTos/SELinux for re-labeling the filesystem and it did not work. Why not? Since you said you had "no issues" figuring it out.

It "did not work" _how_? How did it fail? What was on the console during the relabel?

I've never had a relabel fail. YMMV.

John

On Saturday 07 January 2012 17:23:57 Bennett Haselton wrote:

[root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO -rw-r--r-- apache apache system_u:object_r:file_t /tmp/hostname_SKYSLICE.INFO

Any ideas?

What does

# restorecon -v /tmp/hostname_SKYSLICE.INFO

return?

HTH, :-) Marko

On Sunday 08 January 2012 04:31:05 Bennett Haselton wrote:

[root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO -rw-r--r-- apache apache system_u:object_r:file_t /tmp/hostname_SKYSLICE.INFO [root@g6950-21025 ~]# restorecon -v /tmp/hostname_SKYSLICE.INFO [root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO -rw-r--r-- apache apache system_u:object_r:file_t /tmp/hostname_SKYSLICE.INFO [root@g6950-21025 ~]#

Well...

With this output I would say that your policy has been customized to have file_t as the default label for that file. Have you used audit2allow on that machine before the filesystem was properly relabeled?

I am not sure at this point, but I would say that your SELinux policy has been customized into an inconsistent state (since no file should have the type file_t by default, and yet restorecon says that this is the default label for that file). However, I don't know how to reset the customizations once they have been made (except for the brute force method).

I have never had any machine with SELinux in this kind of state, so I am a bit wary of giving you further advice on this matter. Also, you should probably start a new thread about this problem (quoting the above restorecon output and a brief history of the machine), since more eyeballs would be good in this situation.

As for the brute force method, it would go on the lines of

* disable SELinux * reboot * delete all policy files in /etc/selinux/ * reinstall selinux-policy-targeted via yum * enable SELinux for the next reboot * prepare the autorelabel * reboot

The idea is to get you back to the CentOS default for both the policy and the file labels. However, there may be gotchas above or a more elegant way to restore the default policy, so someone else might chime in with a better advice (Dan?).

HTH, :-) Marko

On 1/8/2012 5:36 AM, Ljubomir Ljubojevic wrote:

On 01/08/2012 02:10 PM, Marko Vojinovic wrote:

...

...

[root@g6950-21025 ~]# restorecon -v /tmp/hostname_SKYSLICE.INFO

...

[root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO -rw-r--r-- apache apache system_u:object_r:file_t /tmp/hostname_SKYSLICE.INFO [root@g6950-21025 ~]#

Well...

With this output I would say that your policy has been customized to have file_t as the default label for that file. Have you used audit2allow on that machine before the filesystem was properly relabeled?

That file is in the /tpm folder, used by apache. I guess that apache was not stopped since/during relabeling so it stayed.

It's a file created by one of my CGI scripts. (The web server is accessed by several hostnames which are dynamically assigned to it, and I need a quick way of determining all hostnames that were recently used to access the server. So when someone accesses the server using HOSTNAME, the file /tmp/hostname_<hostname> is created. Then another script just pulls the names of all of those files in order to find all recently used hostnames.)

My suggestion:

stop apache run relabeling again (if file continues to exists) start apache check

Well when I was doing the relabeling I was doing: # touch /.autorelabel # reboot

So when I'm rebooting apache stops and starts anyway, doesn't it? Doesn't the auto-relabel occur before other services are started up? So I'm not sure what I would actually do differently to follow this suggestion...

On 1/8/2012 7:28 AM, Ljubomir Ljubojevic wrote:

On 01/08/2012 03:15 PM, Bennett Haselton wrote:

...

It's a file created by one of my CGI scripts. (The web server is accessed by several hostnames which are dynamically assigned to it, and I need a quick way of determining all hostnames that were recently used to access the server. So when someone accesses the server using HOSTNAME, the file /tmp/hostname_<hostname> is created. Then another script just pulls the names of all of those files in order to find all recently used hostnames.)

...

My suggestion:

stop apache run relabeling again (if file continues to exists) start apache check

Well when I was doing the relabeling I was doing: # touch /.autorelabel # reboot

So when I'm rebooting apache stops and starts anyway, doesn't it? Doesn't the auto-relabel occur before other services are started up? So I'm not sure what I would actually do differently to follow this suggestion...

Ah, you are write, sorry. Well you might need to apply proper (httpd_) SELinux label for that file. At the time of creation? \ Maybe move it to another location where it will get automatic label for what you want?

Well the warning messages say that file_t files should *never* get created if the filesystem is labeled properly. So I didn't think it was just a matter of creating files where the default filetype would be different, because the default filetype should not be file_t anywhere.

I could create a world-writeable directory somewhere else and have all the scripts write to that but it would be a pain to re-write and re-test everything as a workaround for this one bug...

Well, one other theory: /tmp is a different partition, right? So maybe when I do # touch /.autorelabel # reboot

it's only re-labeling the / partition and not the /tmp one? Unfortunately in that case I don't know how to make it re-label the /tmp filesystem as well. I tried creating /tmp/.autorelabel and rebooting, but that didn't work; /tmp/hostname_SKYSLICE.INFO and other files still had type file_t.

Bennett

On 1/9/2012 3:41 AM, Tony Molloy wrote:

On Sunday 08 January 2012 23:19:39 Bennett Haselton wrote:

...

On 1/8/2012 7:28 AM, Ljubomir Ljubojevic wrote:

...

On 01/08/2012 03:15 PM, Bennett Haselton wrote:

...

It's a file created by one of my CGI scripts. (The web server is accessed by several hostnames which are dynamically assigned to it, and I need a quick way of determining all hostnames that were recently used to access the server. So when someone accesses the server using HOSTNAME, the file /tmp/hostname_<hostname> is created. Then another script just pulls the names of all of those files in order to find all recently used hostnames.)

...

My suggestion:

stop apache run relabeling again (if file continues to exists) start apache check

Well when I was doing the relabeling I was doing: # touch /.autorelabel # reboot

So when I'm rebooting apache stops and starts anyway, doesn't it? Doesn't the auto-relabel occur before other services are started up? So I'm not sure what I would actually do differently to follow this suggestion...

Ah, you are write, sorry. Well you might need to apply proper (httpd_) SELinux label for that file. At the time of creation? \ Maybe move it to another location where it will get automatic label for what you want?

Well the warning messages say that file_t files should *never* get created if the filesystem is labeled properly. So I didn't think it was just a matter of creating files where the default filetype would be different, because the default filetype should not be file_t anywhere.

I could create a world-writeable directory somewhere else and have all the scripts write to that but it would be a pain to re-write and re-test everything as a workaround for this one bug...

Well, one other theory: /tmp is a different partition, right? So maybe when I do # touch /.autorelabel # reboot

it's only re-labeling the / partition and not the /tmp one? Unfortunately in that case I don't know how to make it re-label the /tmp filesystem as well. I tried creating /tmp/.autorelabel and rebooting, but that didn't work; /tmp/hostname_SKYSLICE.INFO and other files still had type file_t.

Bennett _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

First I'm no SELinux expert ;-( but I've ben following this thread with interest. It apears to be going around in circles.

The only time I've come across a file_t type is when I have something on a machine that SELinux doesn't know about. That is SELinux has no policy for it. An example would be if I create a new top level directory when I install a machine. SELinux knows nothing about that directory name and has no preset type for it so it gets a label of file_t or default_t. Doing a relabel in that case will have no affect on the file label as SELinux still doesn't have a policy for it.

So the question is how did your file get the file_t type in the first place. You say it is generated from a cgi script run from apache.

So is this the default apache which comes with CentOS

What is the context of the apache executable. It should be -rwxr-xr-x root root system_u:object_r:httpd_exec_t /usr/sbin/httpd

Yes that's what I've got.

Where in the filesystem is the cgi script located. How did it get there.

What is the context of the cgi script

What is the context of the directory the cgi script is in.

[root@g6950-21025 ~]# ls -lZ /var/www/cgi-bin/capture.cgi -rwxr-xr-x root root system_u:object_r:httpd_sys_script_exec_t /var/www/cgi-bin/capture.cgi [root@g6950-21025 ~]# ls -ldZ /var/www/cgi-bin/ drwxr-xr-x root root system_u:object_r:httpd_sys_script_exec_t /var/www/cgi-bin/

The script got there because I uploaded it there.

What is the context of /tmp. It should be drwxrwxrwt root root system_u:object_r:tmp_t /tmp

Yep. [root@g6950-21025 ~]# ls -ldZ /tmp drwxrwxrwt root root system_u:object_r:tmp_t /tmp

Regards

Tony _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

SELinux has no idea what the labels are in /tmp, so restorecon will not change the labels. It would be best to just remove the content from /tmp and allow new content to be created. If you want the content to be accessible from apache, you could change it to httpd_tmp_t

chcon -t httpd_tmp_t /tmp/PATH

I believe in treating /tmp as temporary and cleaning it out on reboot, or running it as tmpfs.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 01/09/2012 03:00 PM, Marko Vojinovic wrote:

On Monday 09 January 2012 11:45:26 Daniel J Walsh wrote:

...

SELinux has no idea what the labels are in /tmp, so restorecon will not change the labels. It would be best to just remove the content from /tmp and allow new content to be created. If you want the content to be accessible from apache, you could change it to httpd_tmp_t

chcon -t httpd_tmp_t /tmp/PATH

But isn't there a policy for default labelling of arbitrary files put in /tmp? I mean, when apache puts a file in /tmp, it should be labelled *somehow*, according to the rules for apache and/or the /tmp directory, right? This should happen in both enforcing and permissive modes.

So is the default type label for such a case file_t? If it is, it's a bug, since SELinux would deny subsequent access to that file, per policy, right?

If I understood the OP correctly, he enabled SELinux (into permissive mode), relabeled the whole filesystem, rebooted several times, and after all that apache creates a file in /tmp with a label file_t. AFAIK, this should *never* happen, with the default policy.

Or am I missing something?

The only way I can understand how this can happen is to conjecture that the OP has turned on SELinux and --- *before* proper relabelling of the filesystem --- customized the policy (using audit2allow) to allow apache to read/write files of type file_t (this was neither confirmed nor denied by the OP). Since this is inconsistent with other rules in the policy, my suggestion was to "reset" the policy to CentOS default and relabel everything again before making any further customizations. However, I don't know how to actually do the "reset the policy" step, since I never needed it. :-)

Is there an alternative explanation to the whole mess?

Best, :-) Marko

_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

If you look at the file_context file you will see <<none>> which means the default label has no idea what to put in this directory

/tmp/.* <<none>>

This tells restorecon to ignore any files that match this label, to prevent it from doing the wrong thing. restorecon does not understand the difference between file_t or shadow_t or user_home_t. So it does nothing.

So the real problem here is the fact the machine booted with SELinux disabled and them kept files in /tmp. Newer versions of fixfiles attempt to delete these files if it finds them in /tmp.

UNDEFINED=`get_undefined_type` || exit $? UNLABELED=`get_unlabeled_type` || exit $? find /tmp ( -context "*:${UNLABELED}*" -o -context "*:${UNDEFINED}*" ) ( -type s -o -type p ) -delete find /tmp ( -context "*:${UNLABELED}*" -o -context "*:${UNDEFINED}*" ) -exec chcon --reference /tmp {} ; find /var/tmp ( -context "*:${UNLABELED}*" -o -context "*:${UNDEFINED}*" ) -exec chcon --reference /var/tmp {} ; find /var/run ( -context "*:${UNLABELED}*" -o -context "*:${UNDEFINED}*" ) -exec chcon --reference /var/run {} ; [ -e /var/lib/debug ] && find /var/lib/debug ( -context "*:${UNLABELED}*" -o -context "*:${UNDEFINED}*" ) -exec chcon - --reference /lib {} ;

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 01/09/2012 03:24 PM, Tony Molloy wrote:

On Monday 09 January 2012 20:00:29 Marko Vojinovic wrote:

...

On Monday 09 January 2012 11:45:26 Daniel J Walsh wrote:

...

SELinux has no idea what the labels are in /tmp, so restorecon will not change the labels. It would be best to just remove the content from /tmp and allow new content to be created. If you want the content to be accessible from apache, you could change it to httpd_tmp_t

chcon -t httpd_tmp_t /tmp/PATH

But isn't there a policy for default labelling of arbitrary files put in /tmp? I mean, when apache puts a file in /tmp, it should be labelled *somehow*, according to the rules for apache and/or the /tmp directory, right? This should happen in both enforcing and permissive modes.

So is the default type label for such a case file_t? If it is, it's a bug, since SELinux would deny subsequent access to that file, per policy, right?

If I understood the OP correctly, he enabled SELinux (into permissive mode), relabeled the whole filesystem, rebooted several times, and after all that apache creates a file in /tmp with a label file_t. AFAIK, this should *never* happen, with the default policy.

Exactly as I thought. If I touch a file or cp a file into /tmp then it's labelled as tmp_t not file_t. On the other hand if I mv a file in it retains it's original type. So how could a file created in /tmp get a file_t type.

That's why I asked the OP to delete the file and run the script which creates the file by hand.

Tony _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/cento

file_t means the file has no label, so the only way to create this type of file would be to remove the security attributes on the file. On an SELinux system, file_t should never be created, they are only created on a disabled SELinux system. I guess you could try to use chcon -t file_t on a file, but I believe the kernel will block that. Or you could attempt to delete the SELinux label, but that might also be denied.

On Tuesday 10 January 2012 04:05:43 Marko Vojinovic wrote:

On Monday 09 January 2012 15:29:59 Daniel J Walsh wrote:

...

file_t means the file has no label, so the only way to create this type of file would be to remove the security attributes on the file. On an SELinux system, file_t should never be created, they are only created on a disabled SELinux system. I guess you could try to use chcon -t file_t on a file, but I believe the kernel will block that. Or you could attempt to delete the SELinux label, but that might also be denied.

Ok, now I think I understand. The OP has stale files in /tmp which are not labelled, due to not purging /tmp on reboot. SELinux doesn't know how these files should be labelled, so it doesn't even try, and gives them the type file_t, which is a synonym for "this file doesn't have a type".

So the answer for the OP is to use chcon on this file to label it somehow. If that doesn't work, he should delete the file and recreate it (while SELinux is active), so that it gets properly labelled.

I learned something new today. :-) Thanks for the explanation!

Best, :-) Marko

+1

I think I'm finally getting the hang of this SELinux.

Tony

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 01/10/2012 08:37 AM, Bennett Haselton wrote:

On 1/9/2012 8:05 PM, Marko Vojinovic wrote:

...

On Monday 09 January 2012 15:29:59 Daniel J Walsh wrote:

...

file_t means the file has no label, so the only way to create this type of file would be to remove the security attributes on the file. On an SELinux system, file_t should never be created, they are only created on a disabled SELinux system. I guess you could try to use chcon -t file_t on a file, but I believe the kernel will block that. Or you could attempt to delete the SELinux label, but that might also be denied.

Ok, now I think I understand. The OP has stale files in /tmp which are not labelled, due to not purging /tmp on reboot. SELinux doesn't know how these files should be labelled, so it doesn't even try, and gives them the type file_t, which is a synonym for "this file doesn't have a type".

So the answer for the OP is to use chcon on this file to label it somehow. If that doesn't work, he should delete the file and recreate it (while SELinux is active), so that it gets properly labelled.

OK, I did delete the files in the /tmp/ directory, and as the running apache process re-created them, it created them with the correct type: [root@g6950-21025 tmp]# ls -lZ * -rw-r--r-- apache apache system_u:object_r:httpd_sys_script_rw_t hostname_ICECOOK.INFO -rw-r--r-- apache apache system_u:object_r:httpd_sys_script_rw_t hostname_LAZYFROG.INFO etc.

So the documentation is missing something about clearing files out of /tmp/ (or they won't get relabeled properly and processes won't be able to access them under SELinux), but at least it's working now.

Bennett

...

I learned something new today. :-) Thanks for the explanation!

Best, :-) Marko

_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Now if only more people used RHEL we could further enhance the products. :^)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 01/10/2012 09:00 AM, Les Mikesell wrote:

On Tue, Jan 10, 2012 at 7:47 AM, Daniel J Walsh dwalsh@redhat.com wrote:

...

Now if only more people used RHEL we could further enhance the products. :^)

Why isn't it accepted as more of a standard?

I don't understand the question.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 01/10/2012 11:20 AM, Les Mikesell wrote:

On Tue, Jan 10, 2012 at 8:27 AM, Daniel J Walsh dwalsh@redhat.com wrote:

...

On 01/10/2012 09:00 AM, Les Mikesell wrote:

...

On Tue, Jan 10, 2012 at 7:47 AM, Daniel J Walsh dwalsh@redhat.com wrote:

...

Now if only more people used RHEL we could further enhance the products. :^)

Why isn't it accepted as more of a standard?

I don't understand the question.

Why is it vendor-specific to RHEL?

I was talking Money not vendor specific. The question meant as a jab was if more people used RHEL instead of Centos, we could pay more developers. I thought the @redhat.com would signify why I would want that. :^)

On 01/11/2012 05:04 AM, Les Mikesell wrote:

On Tue, Jan 10, 2012 at 1:46 PM, Daniel J Walshdwalsh@redhat.com wrote:

...

...

...

On Tue, Jan 10, 2012 at 7:47 AM, Daniel J Walsh

...

dwalsh@redhat.com wrote:

...

Now if only more people used RHEL we could further enhance the products. :^)

Why isn't it accepted as more of a standard?

I don't understand the question.

Why is it vendor-specific to RHEL?

I was talking Money not vendor specific. The question meant as a jab was if more people used RHEL instead of Centos, we could pay more developers. I thought the @redhat.com would signify why I would want that. :^)

OK, I can understand why you would want that. I don't understand why you think anyone else would want even more nonstandard variations in linux distributions. And if this isn't intended to be vendor-specific, why isn't it an independent upstream project or included in the kernel?

The logical code to SELinux isn't specific to RH, not by a long shot. (Of course, RH may wind up doing some way un-Unixy/very-vendor-specific things in the near future, but that has nothing to do with SELinux) http://userspace.selinuxproject.org/trac http://www.gentoo.org/proj/en/hardened/selinux/ https://wiki.ubuntu.com/SELinux ...

But the difficult thing about SELinux isn't how it works, its the detail required for each policy to wrap each program up correctly without denying useful functionality in the process, not to mention deploying them with packages, and dealing with the whole new universe of inaccurate bug reports SELinux has spawned...

*That* is very hard -- and that is what Red Hat has been so good about over the last while. In the process Fedora has spawned a slew of new tools to make SELinux policy easier to deal with -- and in the process of doing that Fedora acquired/affirmed its reputation for eating babies.

SElinux exists all over the place, and there are binaries for it in nearly every distro -- but nearly everyone has decided that "its too hard" so its just a set of accessory packages almost nobody installs, and if installed not activated, and if activated quickly de-activated (the #1 web server "fix your frustrations on the web" advice for noobs is still "disable SELinux, it sux").

Honestly, though, at this point the tools really are there. A packager that wants to publish an SELinux policy with his package finds it easy if the tools are understood -- what is really lacking now is just a very public, beginner-friendly introduction to the core concepts of SELinux which includes a nice intro to the somewhat arbitrary jargon that surrounds access policy concepts.

Minds are very slowly changing and I am beginning to see a lot more functionality in non-Fedora-derived distros, but it takes a long time to turn the tide several years' worth of mailing archive, newsgroup, blog and forum advice *against* learning SELinux and turning it off instead -- and of course the biggest problem with that advice for those new to SELinux is that often it produces instant gratification.

On Tuesday, January 10, 2012 04:38:27 PM Les Mikesell wrote:

But the hardest part is that these things are application specific and there is no standardization for locations where applications do things. In fact, distributions intentionally move those locations around in their packaging.

Good morning, Les.

Distribution differences are the price we pay for choice. Distributions are (and should be) free to put things where they see fit. Each major distribution I've looked at has had good reasons for the different choices that they have made.

That reputation is well deserved. Would it not have made sense to have the needed diagnostic tools before shipping the thing that needs it?

No, it wouldn't have. With open source being a 'scratch your own itch' thing, and with Fedora well-placed in the 'hobbyist/enthusiast/not a normal user' domain, this somewhat 'forces' the issue of getting things fixed. Otherwise things would likely not have been fixed at all.

And wouldn't it have been a good idea to have the documentation before turning on something non-standard that breaks things?

If Fedora were a commercial product, sure. It isn't; documentation follows code in open source, full stop. Whether that's the way it should be or not, it is the way it is, and I for one prefer true developer freedom to choose the way to develop. If an open source development group wants to write docs first, and then implement, they have the freedom to do so. If a development group doesn't want to write any documentation at all, but just hand out the source, then that development group has the freedom to do so (and users have the freedom to use or not use that software). Companies wanting to productize open source should do their homework and write their own docs; Red Hat for one has done that, and the docs are quite good.

Yeah, the whole idea seems like what a car company would have to do to come back after selling a model that gets a lot of publicity for crashing and burning. The earlier opinions weren't wrong, after all.

You have the wrong analogy. Linux today is in a state quite similar to the state of the automotive industry before Henry Ford. Every car was unique, parts didn't interchange, roads were a mess, and people as hobbyists/enthusiasts built their oen cars (not from kit parts like most of today's auto enthusiasts) from scratch. Or the days of airplanes prior to World War I. Things did crash and burn, and it was an enthusiast's world.

And thus far no one of whom I am aware has died due to an SELinux problem.

On Wednesday, January 11, 2012 10:47:44 AM m.roth@5-cent.us wrote:

I'll have to disagree, Lamar. There *are* large distros: RH & its derivatives, SuSE, and Debian & its derivatives (i.e., Ubuntu), and though there are kit distros (fedora?), they're more like the Big Three automakers of the US, and I can't think of frequent crash&burn reports.

In terms of commercial distributions, I see more of an analogy to REO, Hupmobile, Duesenburg, and Studebaker than the current large automakers.

The history of automobiles and auto manufacturers is educational, even to the 'patent wars' going on (like the Selden two-stroke patent that was overturned in 1911).

Using the auto analogy, I would compare the current state of open source OS's to the dawn of the 'Brass' Age of autos. (We're past the 'veteran' stage, which started roughly about the time Red Hat and SuSE started their respective Enterprise Linux distributions, IMO; prior to that it was most definitely an enthusiast's world).

On Wednesday, January 11, 2012 12:06:31 PM Les Mikesell wrote:

I was thinking more of Ford getting people to forget about the Pinto - which I think they have done fairly successfully although it may just have to do with aging memory. Let's see, that was around 1980. Maybe I'll try Fedora again in 30 years.

'Unsafe at any speed'

Still not a great analogy, though, since the Pinto (and the Corvair) were oriented towards the normal user; Fedora is more of a 'concept car' thing.

SELinux and kin are much like seatbelts; they can save your life in a crash, but people tend to worry about the annoyances and the corner cases like that of being trapped underwater (the pressure on the door is a bigger problem than a stuck seatbelt, as Mythbusters demonstrated to good effect....).

And seatbelt latches have gotten better.....

On Wednesday, January 11, 2012 01:22:05 PM Les Mikesell wrote:

I don't think of myself as a 'normal user', but I still don't appreciate it when a distribution goes out of its way to arbitrarily modify and break what application developers spent years designing and writing.

SELinux does not 'go out of its way' to 'break' anything; rather, SELinux enforces a deny by default 'need to access' policy.

I still remember when simple packet filtering firewalls first came out, and those with a 'default deny and allow only what you specify' policy were much more difficult to properly configure than those with a 'default allow and block only what you specify' policy. Default deny is the correct way to firewall, but it does require much more work, as you need to know what your traffic actually looks like, and you may need to put in some 'helper' applications and connection trackers for things like ftp and H.323.

SELinux is no different in concept, it just brings the access control paradigm onto a much more detailed internal level instead of just being on the network like a simple packet filter would be.

If you need to special-case stuff, then you need to do an analysis of the special cases you need to create; this is what a testing server running SELinux in permissive mode is for, as there is no better analysis of what SELinux needs than SELinux in permissive mode loggin what your application is using. Get the logs and run audit2allow and package that as a piece of your applications' SELinux policies.

That is new, but it isn't very hard.

On 01/12/2012 04:49 AM, Les Mikesell wrote:

On Wed, Jan 11, 2012 at 1:23 PM, Lamar Owenlowen@pari.edu wrote:

...

On Wednesday, January 11, 2012 01:22:05 PM Les Mikesell wrote:

...

I don't think of myself as a 'normal user', but I still don't appreciate it when a distribution goes out of its way to arbitrarily modify and break what application developers spent years designing and writing.

SELinux does not 'go out of its way' to 'break' anything; rather, SELinux enforces a deny by default 'need to access' policy.

Yes, the breakage came from having someone who didn't understand the needs define that policy.

I think you are misunderstanding how SELinux policies are formed and how they work. Its a *lot* less complicated and mysterious than you're making it sound. For most applications its really, really easy to do this.

...

If you need to special-case stuff, then you need to do an analysis of the special cases you need to create; this is what a testing server running SELinux in permissive mode is for, as there is no better analysis of what SELinux needs than SELinux in permissive mode loggin what your application is using. Get the logs and run audit2allow and package that as a piece of your applications' SELinux policies.

So if an application only needs to do something once at some future time, what happens? If you write an application that will need to do something at some rare future time, what is the standard way to tell distribution packaging systems and system administrators to permit it?

I'm trying to think of a single example (that isn't a worm) that fits this description.

Can you think of any examples? (again, worms don't count... actually, that is sort of the point here...)

...

That is new, but it isn't very hard.

Doesn't that really depend on what the application needs to do?

No, there are tools that do almost all the work for you. Its much easier than learning how to write a spec file in the first place. At this point it sounds like you're just arguing against something you're refusing to find out more about -- which is the standard human policy towards SELinux, so you're in good company (it used to be the standard human policy toward ipchains back in the day, too).

You can just turn it off if it bothers you so much.

On Wednesday, January 11, 2012 02:49:29 PM Les Mikesell wrote:

On Wed, Jan 11, 2012 at 1:23 PM, Lamar Owen lowen@pari.edu wrote:

...

SELinux does not 'go out of its way' to 'break' anything; rather, SELinux enforces a deny by default 'need to access' policy.

Yes, the breakage came from having someone who didn't understand the needs define that policy.

'Going out of its way to break' something means knowing what is needed for something to work, and intentionally preventing it from working. I'm reminded of DR-DOS years ago....

You can't intentionally break the thing of which you weren't aware; such breakage is not intentional.

... what is the standard way to tell distribution packaging systems and system administrators to permit it?

An SELinux policy set. Seriously. Set up variables or whatnot to specify filepaths if you need to.

...

That is new, but it isn't very hard.

Doesn't that really depend on what the application needs to do?

No, unless the application is doing something dangerous. OpenNMS (for one) does some dangerous (in the security context) things, but the RPM packages I've run 'just worked' from the repository, to the best of my recollection (I did some fairly major network reconfiguration, and need to reinstantiate my OpenNMS instance, and when I do it will be on a different VM running C6, assuming the OpenNMS yum repo is up to date).

If the application needs to do wierd things, then the application developer (or some member of the development team, or a user of that package, or the packager (if there is one)) needs to write the SELinux policy and bundle it for those who need it. Simple as that; CentOS and other rebuilds of upstream EL are common enough that SELinux is out there pervasively, so there's really no excuse.

Telling people 'turn SELinux off' shouldn't cut it any more.

On Wed, Jan 11, 2012 at 01:49:29PM -0600, Les Mikesell wrote:

On Wed, Jan 11, 2012 at 1:23 PM, Lamar Owen lowen@pari.edu wrote:

...

SELinux does not 'go out of its way' to 'break' anything; rather, SELinux enforces a deny by default 'need to access' policy.

Yes, the breakage came from having someone who didn't understand the needs define that policy.

I think part of the problem is that Linux+SELinux is a _different platform_ to Linux without SELinux.

On any Unix or Linux system I can install apache, configure it so that DocumentRoot is /mywebtree/htdocs, CGIs are in /mywebtree/cgi. The CGI can write to /myapp/tmpdir and so on. And it will work the same way on all of those platforms. On Linux+SELinux, however, you need to do additional work. The platform needs to be configured to allow this to work.

Developers need to target Linux+SELinux as if it was a new platform to be supported.

But what about the gazillion of apps that don't support that platform? Either you disable SELinux or you have a large support overhead (initial onboarding of app, verification that updates to app still work, verification that OS updates don't break app, etc etc).

Is the additional security worth it?

Maybe. Maybe not. That's up to each individual to determine.

On Wed, Jan 11, 2012 at 9:15 AM, Lamar Owen lowen@pari.edu wrote:

On Tuesday, January 10, 2012 04:38:27 PM Les Mikesell wrote:

...

But the hardest part is that these things are application specific and there is no standardization for locations where applications do things.  In fact, distributions intentionally move those locations around in their packaging.

Good morning, Les.

Distribution differences are the price we pay for choice.  Distributions are (and should be) free to put things where they see fit.  Each major distribution I've looked at has had good reasons for the different choices that they have made.

If the first thing you saw on a unix-like system was the horror of autoconf, would you have taken a second look? This is an even worse situation, because there is no equivalent way to describe what you want across flavors. I'm not saying that distribution packagers shouldn't be free to break whatever applications they want, and that sysadmins shouldn't be allowed to break even more, I'm saying it would be better if that didn't happen because they didn't understand what the application writer intended. How is the application developer (unquestionably the expert on the application needs) supposed to describe those needs to SELinux in a way that can work across distributions without 'less-expert' people guessing about them?

You have the wrong analogy.  Linux today is in a state quite similar to the state of the automotive industry before Henry Ford.  Every car was unique, parts didn't interchange, roads were a mess, and people as hobbyists/enthusiasts built their oen cars (not from kit parts like most of today's auto enthusiasts) from scratch.  Or the days of airplanes prior to World War I.  Things did crash and burn, and it was an enthusiast's world.

I guess you are right about the state of the art and that it is as wrong to expect things to work as it was to expect flying cars by now. But it would have been fun.

On 1/10/2012 12:52 PM, 夜神　岩男 wrote:

On 01/11/2012 05:04 AM, Les Mikesell wrote:

...

On Tue, Jan 10, 2012 at 1:46 PM, Daniel J Walshdwalsh@redhat.com wrote:

...

...

...

On Tue, Jan 10, 2012 at 7:47 AM, Daniel J Walsh

...

dwalsh@redhat.com wrote: > Now if only more people used RHEL we could further enhance > the products. :^) > Why isn't it accepted as more of a standard?

I don't understand the question.

Why is it vendor-specific to RHEL?

I was talking Money not vendor specific. The question meant as a jab was if more people used RHEL instead of Centos, we could pay more developers. I thought the @redhat.com would signify why I would want that. :^)

OK, I can understand why you would want that. I don't understand why you think anyone else would want even more nonstandard variations in linux distributions. And if this isn't intended to be vendor-specific, why isn't it an independent upstream project or included in the kernel?

The logical code to SELinux isn't specific to RH, not by a long shot. (Of course, RH may wind up doing some way un-Unixy/very-vendor-specific things in the near future, but that has nothing to do with SELinux) http://userspace.selinuxproject.org/trac http://www.gentoo.org/proj/en/hardened/selinux/ https://wiki.ubuntu.com/SELinux ...

But the difficult thing about SELinux isn't how it works, its the detail required for each policy to wrap each program up correctly without denying useful functionality in the process, not to mention deploying them with packages, and dealing with the whole new universe of inaccurate bug reports SELinux has spawned...

*That* is very hard -- and that is what Red Hat has been so good about over the last while. In the process Fedora has spawned a slew of new tools to make SELinux policy easier to deal with -- and in the process of doing that Fedora acquired/affirmed its reputation for eating babies.

SElinux exists all over the place, and there are binaries for it in nearly every distro -- but nearly everyone has decided that "its too hard" so its just a set of accessory packages almost nobody installs, and if installed not activated, and if activated quickly de-activated (the #1 web server "fix your frustrations on the web" advice for noobs is still "disable SELinux, it sux").

Honestly, though, at this point the tools really are there. A packager that wants to publish an SELinux policy with his package finds it easy if the tools are understood -- what is really lacking now is just a very public, beginner-friendly introduction to the core concepts of SELinux which includes a nice intro to the somewhat arbitrary jargon that surrounds access policy concepts.

Well there is already a beginner-friendly introduction: http://wiki.centos.org/HowTos/SELinux The problem I had with it is that there are several statements that are unclear, missing, or just wrong. That's not necessarily the fault of the author; if I had to write an intro to something that I knew a lot about, I'd probably also make a few statements that were unclear or wrong.

The cure for that is to show it to 10 people whose intelligence you are reasonably confident about, but who *don't already know* what the document is trying to teach, and ask them to suggest edits: anything that tells the user to "do something" without saying how, or is unclear, or doesn't work when they try it. Then when the documentation has been tweaked enough that it no longer has too many of those problem areas, then it's "ready".

(If I were a volunteer, some of my suggested edits to that page would be: - Near the beginning the doc says "the machine should be rebooted and the filesystem relabeled", without telling the user how to actually do that. Have a forward-reference telling the user where to read how to relabel the filesystem. - The sentence about "Access is only allowed between similar types" is apparently wrong (and meaningless anyway if it doesn't explain what "similar types" means). I would just go ahead and say that there's no way to know for sure what process types will be allowed to access what file types, and all you can do is make educated guesses based on the similarity of the names, and then look at error logs afterwards to see if you were right. - Explain that files in /tmp/ aren't relabeled after rebooting. (If indeed that is the case. We never did figure out why my /tmp/ files weren't being relabeled.) - The "genhomedircon" command gives an error if SELinux is enforcing; switch to permissive before running that command. - The doc says httpd runs in the httpd_t security context. This is only true if it's started silently; if the user starts it from the command line, it runs in a different context.)

It doesn't take that much work to turn so-so documentation into really useful documentation, but you have to start with the assumption that there is room for improvement. The main obstacle is the attitude of people like John Dennison, who assume the documentation is fine the way it is, and that any problems are therefore the fault of the user: "If people would bother to spend some time _reading_ _documentation_ on the systems they are attempting to admin they might find that subsystems such as selinux aren't quite as complex as they make them out to be... Blaming selinux itself for creating what you perceive as a "problem" because you won't make a rudimentary attempt at learning to properly manage it is ludicrous." (Even though it subsequently came out that I was in fact following the instructions on the wiki, and there were steps missing in the instructions.)

Why not try producing documentation that passes the 10-smart-newbies test, and then point people to that, whenever they run into problems caused by SELinux?

But if it takes an average of four days to fix a typical problem caused by SELinux, *even following the documentation* (and even, for that matter, having a whole list to help you!), then of course people aren't going to use it.

Bennett

Minds are very slowly changing and I am beginning to see a lot more functionality in non-Fedora-derived distros, but it takes a long time to turn the tide several years' worth of mailing archive, newsgroup, blog and forum advice *against* learning SELinux and turning it off instead -- and of course the biggest problem with that advice for those new to SELinux is that often it produces instant gratification. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On 1/11/2012 5:32 AM, 夜神　岩男 wrote:

On 01/11/2012 07:19 PM, Bennett Haselton wrote:

...

Well there is already a beginner-friendly introduction: http://wiki.centos.org/HowTos/SELinux The problem I had with it is that there are several statements that are unclear, missing, or just wrong. That's not necessarily the fault of the author; if I had to write an intro to something that I knew a lot about, I'd probably also make a few statements that were unclear or wrong.

Tell me about it. I constantly find myself really great at writing docs for systems that the audience is already expert in, but somewhat lacking on writing it for complete beginners. Really, the principal problem is one of prereqs. Teaching people on this list about SELinux is a lot easier than teaching professional diesel mechanics about it, and a bit harder than teaching a certain breed of security researchers about it. So at what level is appropriate to begin the explanation? This is tricky.

I agree that's always a tricky question, but I think the problem here was that even if you knew a lot about Linux but just happened to be unfamiliar with SELinux, the documentation was still incorrect in ways that the reader wouldn't be able to figure out on their own. When the doc says "Access is only allowed between similar types", you can't make head or tail of that unless you already know what it means.

...

The cure for that is to show it to 10 people whose intelligence you are reasonably confident about, but who *don't already know* what the document is trying to teach, and ask them to suggest edits: anything that tells the user to "do something" without saying how, or is unclear, or doesn't work when they try it. Then when the documentation has been tweaked enough that it no longer has too many of those problem areas, then it's "ready".

This is sounds very much the way open source development works. And its the process you're engaging in, actually. See below...

Yes, for software. But I've never heard of it being done for documentation. I suspect this is for two reasons: (1) if software fails, the dev does has to bite the bullet and make it work, but if documentation "fails", it's easy to blame the user (reader); (2) to get help testing your software, you can stay within the community of people who helped right it or those closely connected to them, but to get help testing documentation, you have to reach out to people far removed from your inner circle. (Plus, in theory you can only test the document on a single person one time. You can't use them to test future iterations of the same document, because then they might incorrectly report that the document is getting "clearer" when really their understanding is just becoming clearer from multiple readings and back-and-forth with the authors.)

...

(If I were a volunteer, some of my suggested edits to that page would be:

• Near the beginning the doc says "the machine should be rebooted and

the filesystem relabeled", without telling the user how to actually do that. Have a forward-reference telling the user where to read how to relabel the filesystem.

• The sentence about "Access is only allowed between similar types" is

apparently wrong (and meaningless anyway if it doesn't explain what "similar types" means). I would just go ahead and say that there's no way to know for sure what process types will be allowed to access what file types, and all you can do is make educated guesses based on the similarity of the names, and then look at error logs afterwards to see if you were right.

• Explain that files in /tmp/ aren't relabeled after rebooting. (If

indeed that is the case. We never did figure out why my /tmp/ files weren't being relabeled.)

• The "genhomedircon" command gives an error if SELinux is enforcing;

switch to permissive before running that command.

• The doc says httpd runs in the httpd_t security context. This is only

true if it's started silently; if the user starts it from the command line, it runs in a different context.)

And you should *really* cc this bit to the author. Anyway, you said it is a wiki -- so why don't you get to wikifying instead of writing on a mailinglist? That's the heart of the process! This is a system under development, and as such needs your help. How great would it be for you to document your trouble spots in learning and contribute that back?

I wasn't going to get into this, but... I did find the wiki contact page, and join their e-mail list, and post to the list asking to create an edit account so that I could make an edit (for starters, after the sentence about "you should re-label the file system", I was going to add a link to the steps on how to do that). I got one reply, replied to that, and the thread went dead. Here it is: http://lists.centos.org/pipermail/centos-docs/2012-January/thread.html

Now, I understand if I kept bugging them, they might get back to me, and maybe my precious edit would actually happen. I think it's more of a mindset thing. Why not recruit some outsiders *before* the instructions ever even went live on the web, and say, "Here, read this, does it make sense to you?"

Most of the best tutorials on the web started that way -- as a "how to learn how to learn systemX based on my personal experience" type of document. A roadmap for learning is never more accurate than the one written by a learner himself.

There is a secondary benefit to this -- it forces you as a learner to really understand your subject, which makes the learning more complete for you. Its a win-win, give it a spin! If nobody did that we wouldn't even have a kernel, by the way...

Well yes, sometimes you do end up learning more about a system, if you start out with wrong instructions, and you have to do a lot of asking and messing around to figure out why the instructions aren't working. But I think that's mainly because you have to spend far longer at it, than you would have spent, if the original instructions had worked.

Given a *fixed* quantity of time to spend learning something, I think it would be far more productive to follow a set of instructions that guided you through actually doing several different things for practice (and which were correct instructions :) ), then banging away at one thing figuring out why it's wrong. Yes, I know that /tmp/ files don't get re-labeled properly, but that's pretty much the only thing I know.

...

It doesn't take that much work to turn so-so documentation into really useful documentation, but you have to start with the assumption that there is room for improvement. The main obstacle is the attitude of people like John Dennison, who assume the documentation is fine the way it is, and that any problems are therefore the fault of the user: "If people would bother to spend some time _reading_ _documentation_ on the systems they are attempting to admin they might find that subsystems such as selinux aren't quite as complex as they make them out to be... Blaming selinux itself for creating what you perceive as a "problem" because you won't make a rudimentary attempt at learning to properly manage it is ludicrous." (Even though it subsequently came out that I was in fact following the instructions on the wiki, and there were steps missing in the instructions.)

He's right in principle, if not in detail. You're right in principle, but you're also correct in the specific detail of practice as things stand right now. Every system we use is a moving target. JD was probably dead-on correct a few months ago. Things have changed, and the documentation likely doesn't take into account the specific version of the distro you're running, so some things could be missing. This happens a LOT, and its not really anyone's fault, per se -- that is entirely the wrong way of looking at it, especially in the open source world.

...

Why not try producing documentation that passes the 10-smart-newbies test, and then point people to that, whenever they run into problems caused by SELinux? But if it takes an average of four days to fix a typical problem caused by SELinux, *even following the documentation* (and even, for that matter, having a whole list to help you!), then of course people aren't going to use it.

You went from nearly zero understanding to finding the solution in four days. In that span you didn't just "find the solution" as something that you cut and pasted from a forum without knowing what you were doing. You actually learned a bit about the system itself. This was what you initially lacked, but have now.

Yes but at what cost? A lot of other things that I need to be working on, had to get put on hold because I have to figure out how to lock down the systems using SELinux, and spent four days working around one mistake in the documentation. (As I said, if someone's going to spend four days learning something, it's better to have self-guided lessons showing how to do multiple things -- but have the self-guided lessons proofread by outsiders :) )

A lot of people coming from Windows spend well over a day just to make heads or tails of the Unix file permissions system, and longer than that when they have a real file permissions question that involves things like sticky group permissions on directories, for example. On the other hand millions of people literally spend hundreds of hours every month clicking mouse buttons at work on full salary to do things that a script could daily/hourly/whenever in less than a second -- but they don't take the time to learn how to do things like that because it (ironically) "seems like too much of a hassle". Hell, the entire concept of the web as an "applications development framework" is completely flawed but based on the premise that doing the required cheetahflips to make the web almost sorta-kinda secure is better than learning how real secure socket communications can work and taking the time to study just one or two languages and a single applications library deeply. The world is full of mistakes based on instant gratification, pretty pixels, chicken lipstick and fake tits that could have easily been prevented by prior planning and self-education.

Blah blah blah. You did extremely well learning what you needed to and sticking with it (most people just give up, but instead you decided to learn -- which, over time, is how people accidentally get added to the development community, by the way).

Yes but I'm not sure if I made the right decision -- all that time lost was time I spent on other things. (Did anyone get the idea from the passwords/keys threads that I am a bit tenacious? :) )

But in the big picture it doesn't matter whether you think *I* made the right decision, if the vast majority of people are never going to invest that much time, and as a result, most people will just turn off SELinux instead. You can make one person's webserver more secure by encouraging them to read more, but you can only make the web as a whole more secure by making *defaults* better and making it a less arduous process to turn on things that are supposed to improve security.

You could deepen that by documenting your experience even on just a personal blog or whatever and linking it from the wiki, or just letting Google catch it... others *will* be interested! _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On Tue, Jan 10, 2012 at 3:26 PM, Daniel J Walsh dwalsh@redhat.com wrote:

Again, there is nothing that we do that is Vendor specific, Everything we do with SELinux is open source.  We are working to get our stuff upstream.

I have no idea what you are talking about as far as variations in Linux Distributions.  I work regularly with people in Centos, RHEL, gentoo, ubunto, debian, fedora and today even Mandriva.  SELinux was just released for android also.  As I tweeted yesterday.

OK, so the part that breaks things is getting widely shipped. Are the parts that make each specific application work again getting pushed upstream into the corresponding projects?

On Tue, Jan 10, 2012 at 3:50 PM, Daniel J Walsh dwalsh@redhat.com wrote:

...

...

That is not the way it works.  SELinux Reference policy is a database of rules that govern the default ways application run.

Yes, but it is application developers that know what their applications need to do. Is there a way for them to express that?

These rules that have been written for Fedora/RHEL are public and are being moved upstream.

There has to be a better approach than letting the Fedora guys second-guess where application components should live, then second-guess what the application needs to do. In fact, that sounds like a recipe for years of problems for everyone who uses the results.

Different Distributions can choose to use these policies or write there own.

So after the Fedora version of second-guessing, that gets pushed off to other distributions to likely make it even worse?

Out of the Reference Policy you can build your own version of targeted or MLS policy or you can write your policy from scratch.

But is there a way that these can originate from the group that manages the application, and appear automatically as a result in distributions that include the application or if you compile from the source distribution?

The place that SELinux breaks applications is when an application does something that SELinux did not expect.

Well, of course. The issue is how SELinux is supposed to learn from the person who does know what the application is going to do. I don't run an OS distribution to what a distribution does, I run it so it does what the application is supposed to do. That is, the application is the point, not what SELinux guesses it was supposed to do.

I wrote a paper and presentation on the four main causes of SELinux issues.

http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_t...

Don't these all boil done to SELinux not understanding the application's needs?

2012/1/11 夜神　岩男 supergiantpotato@yahoo.co.jp:

...

...

That is not the way it works. SELinux Reference policy is a database of rules that govern the default ways application run.

Yes, but it is application developers that know what their applications need to do. Is there a way for them to express that?

This gets back to the core problem of people often just not learning SELinux in the first place. Its not RH or Fedora's problem if upstream developers trying to port Windows apps to Fedora dont, for example, understand Unix permissions.

No, that's not the issue. The issue is that RH and Fedora have consistently shipped kernels and glibc's (etc., etc.) full of flaws that are trivially exploited to let anyone become root, and then they try to slap bandaids on the applications in a so-so attempt to keep things from being able to get to those vulnerabilities.

...

So after the Fedora version of second-guessing, that gets pushed off to other distributions to likely make it even worse?

I'm assuming this is a joke. Fedora already ate (almost) all the babies.

No, its not a joke. Doctors get to bury their mistakes, but this is more of an architectural issue where the best you can do is plant vines to cover up a bad design. The vines may have grown over old applications, but if I were to write a new one today, how would I include a configuration that would work regardless of the distribution?

Seriously. I lived through it and now I find SELinux a breeze, and audit2allow is *really* quite a livable tool to work with. You're talking like other distro's burden somehow belongs to Fedora.

Leave Fedora out of the picture. The burden (or capabiliy, depending on how you look at it) should belong to the application designer. SELinux needs a way for the application designer to tell it what to permit the application to do. Anything else is equivalent to every distribution needing to go rewrite the mode parameters on every open() in every application before the app will work.

Fedora's burdens aren't even RH's problem -- RH only picks what it finds as useful for its customer base out of Fedora, and SELinux is very high on the list of "incredibly useful things". But just like PostgreSQL, Sendmail, Apache2, Bash, Awk, Sed (the list is long) all the really powerful stuff, new or old, requires some study.

Study? Do you mean that people who don't understand them are making these changes? And you expect them to get it right?

You're expecting to get a system-wide mandatory access control policy system across every distro based solely on Fedora's efforts (as if Fedora is actively pushing SELinux to other distros) without the users/sysadmins needing to do some reading? When was the last time you ever heard of a safe, secure, all-encompassing web (or otherwise) CMS, for example, that didn't require at least some configuration and knowhow?

You have it backwards. I'm saying it needs the knowhow of the upstream application developer, not someone guessing at what they meant to do.

SELinux policy is not the hardest thing a packager has to deal with, IMO.

Can you quantify that - like with the number of Fedora bugs it produced?

That's what the auditing tools can help you out with. Outside of that, you're asking for Microsoft-style defaults, which is ridiculous.

Beg your pardon?

There is no way, for example, that you could consider it a sane default to permit Apache, on a basic installation, to automatically index directories and serve files from NFS mounted /home partitions and call that secure -- and definitely not to do so while invoking background code that resides in those directories, sending mail out or exercising any sort of database access (which I guess would have to also all be enabled in your favored default policy?).

I don't understand your point here. Are you saying that SELinux is not well matched to typical tasks on Linux systems?

Complaining or insisting that Fedora or RH somehow magically fix packaging policy for every other distribution, however, are not realistic options,

Having distribution packagers make these changes doesn't make any more sense than having them write the application source code in the first place.

nor is "Yeah, I *want* it to enforce stuff, but I don't want to know what those things are, how they work or to ever have to explain those things to the system when its at a loss amongst the millions of interactions which occur in my system every second or the billions of potential states which can arise.

I consider the application writer to be the expert here, and would like just as little intervention by the packagers and sysadmins as we can get away with while the distributions keep shipping kernel and glibc vulnerabilities.

I also refuse to read the man pages for chmod and chown. The system should just know who owns what and why, the way Windows used to -- now *that* was slick!"

You are out of line there. chmod and chown are well documented and follow standards. And if an application runs them, they work in spite of most distributions efforts to break standards and emulate proprietary systems to lock you in. And if I run them, I expect them to work exactly the same on anything that claims to resemble unix or Posix.

On Saturday 07 January 2012 05:39:15 Bennett Haselton wrote:

On 1/7/2012 5:25 AM, John R. Dennison wrote:

...

On Sat, Jan 07, 2012 at 04:43:31AM -0800, Bennett Haselton wrote:

...

Virtually every hosting company I've ever bought a CentOS server from has had SELinux turned off by default. (So, a partial list would include FDCServers, Superb.net, SiteGenie, SecuredServers (ho, ho), AeroVPS (sells dedicated servers despite their name), Netelligent, ServerBeach and I don't remember all the others). Don't hold me to that list 100% since some might have changed their policies for new servers but it's pretty universal.

Then these companies should be universally boycotted as it's pretty evident that they don't place security at the top of the importance stack.

People that don't run selinux deserve _everything_ they get and then some.

[snip]

Apparently the marketplace favors hosting companies turning SELinux off because the failures it causes are too obscure and it causes too many support headaches.

Ignorance is bliss... ;-)

A hosting company should certainly have SELinux turned on by default. A customer who doesn't know how to handle it should be told to RTFM. If they don't want to deal with SELinux, they can easily turn it off themselves (at their own responsibility).

This is analogous to having a rent-a-car agency renting cars without safety belts, because "they are inconvenient for the users and most people don't put them on anyway". Being irresponsible cannot be justified with what marketplace does or does not favor.

A non-changing-human-nature solution might be to notify the user directly when SELinux blocks something. The GUI apparently already does this via a dialog box when viewing a desktop; perhaps there's a way to do it on the command line too. (When the user runs something that's blocked by SELinux, just send a message to the terminal saying "SELinux blocked this", or something. Would be a start.)

Sometimes there is a message on stderr about "permission denied" or such. But in general every AVC denial is written in /var/log/audit/audit.log. There are also setroubleshootd and sealert, to help you "translate" the AVC denial into something more user-friendly, and suggest what to do about it.

HTH, :-) Marko

On Saturday, January 07, 2012 11:15:35 AM Bennett Haselton wrote:

Hence the idea for having SELinux send messages to the terminal saying "SELinux blocked such-and-such". There's probably some better way.

Huh?

CentOS has done this by default since CentOS 4. At least I see SELinux-generated 'denied' AVC's on a couple of internal C4 machines where I'm running SELinux in permissive mode and I see the denials on a text console. All my CentOS 5 boxes have SELinux on and enforcing, but I haven't seen any avc denials in the logs or on the console, nor have I done anything 'wierd' on those boxes....

The graphical GNOME installation pops up a tooltip-style balloon when SELinux denials are found, at least with CentOS 6. Haven't tried with C5.

Now, nowhere in the logged message does it say 'SELinux' but a google for the text found in such an avc denial log entry brings up what you need to know. Here's an example: audit(1325941406.515:467): avc: denied { write } for pid=6609 comm="postmaster" name="1262" dev=dm-0 ino=2016007 scontext=root:system_r:postgresql_t tcontext=user_u:object_r:var_t tclass=file

(I know how to fix it, I just haven't). This by default comes to the /dev/console device along with being logged in dmesg and elsewhere.

On 1/7/2012 9:41 AM, Marko Vojinovic wrote:

On Saturday 07 January 2012 08:15:35 Bennett Haselton wrote:

...

On 1/7/2012 6:50 AM, Marko Vojinovic wrote:

...

On Saturday 07 January 2012 05:39:15 Bennett Haselton wrote:

...

Apparently the marketplace favors hosting companies turning SELinux off because the failures it causes are too obscure and it causes too many support headaches.

Ignorance is bliss... ;-)

A hosting company should certainly have SELinux turned on by default. A customer who doesn't know how to handle it should be told to RTFM.

See what I wrote to John about "should-statements"... you can't change human nature, but you can make better defaults.

What do you mean by "better" defaults? Better for the user, or better for the hosting company? Better in terms of quality/security, or better in terms of ease of use?

There is no obvious "better" default, IMHO. This is about trading security for convenience, and if a hosting company puts convenience before security, they are doing a lousy job. Turning off SELinux is a choice that should be done by the *customer*, not by the hosting company.

I am still waiting for the day when SELinux will become completely mandatory, just as the owner/group permissions are today. ;-)

...

...

Sometimes there is a message on stderr about "permission denied" or such. But in general every AVC denial is written in /var/log/audit/audit.log. There are also setroubleshootd and sealert, to help you "translate" the AVC denial into something more user-friendly, and suggest what to do about it.

Yes, once you know that SELinux is the cause, the tools for diagnosing what to do are pretty helpful. But what hosting companies care about -- in terms of inconvenience to the user -- is that there's no easy way to find out for the first time that SELinux is the cause of something not working.

Hence the idea for having SELinux send messages to the terminal saying "SELinux blocked such-and-such". There's probably some better way.

Well, when something gets blocked by iptables, that doesn't even get into a log, let alone interactive messages. An administrator needs to be intelligent enough to *guess* that the app doesn't work because some port might be closed by the firewall. That's even worse than the situation with SELinux, and nobody has ever "fixed" that one in decades. :-)

Well, yes there would be fewer usability issues if it did send a message to the user. Although, a firewall is something that a user might be more likely to guess about, because firewalls exist on every OS and have for a long time, but SELinux is Linux-only and apparently only one some distros.

I guess it could be easily implemented, though. All AVC denials are being communicated via dbus, and can probably be caught and sent to a terminal as well. Read man audispd and related stuff --- I guess one can customize the relevant log daemon to send messages to the terminal too, in addition to the log file.

If you manage to customize it, send us the recipe, I guess it could be helpful for others as well. :-)

I don't need it for myself, now that I know to look in the logs :) The point was to make it more discoverable for users who may not realize it's turned on and why their new server app isn't working.

Bennett

On 1/7/2012 5:57 AM, Marko Vojinovic wrote:

On Saturday 07 January 2012 04:43:31 Bennett Haselton wrote:

...

On 1/7/2012 4:16 AM, Marko Vojinovic wrote:

...

IMHO, if a hosting company does that sort of things (especially turning off SELinux), I wouldn't touch them with a ten-foot pole. Who knows what else they might have customized, in their infinite wisdom... :-)

Care to share the name of that hosting company?

Virtually every hosting company I've ever bought a CentOS server from has had SELinux turned off by default. (So, a partial list would include FDCServers, Superb.net, SiteGenie, SecuredServers (ho, ho), AeroVPS (sells dedicated servers despite their name), Netelligent, ServerBeach and I don't remember all the others). Don't hold me to that list 100% since some might have changed their policies for new servers but it's pretty universal.

What hosting company sells sub-$100 unmanaged CentOS dedicated servers and *doesn't* have SELinux turned off?

I wouldn't know, I don't use such services (typically I have my production systems on my own hardware). And now that you say most of them turn SELinux off by default, I am discuraged to even consider having my system hosted by such companies... ;-)

...

...

...

As for the original question -- when the docs say that access is allowed only across "similar types", what determines what counts as "similar types"? How do you know for example that httpd running as type httpd_t can access /var/www/html/robots.txt which has type httpd_sys_content_t?

AFAIK, the interactions between various labels (ie. rules "who can access what") are determined by the SELinux targeted policy (the selinux-policy- targeted package). These rules evolve over time (the package sometimes gets updated and your filesystem autorelabeled to match), and IIRC they can get pretty complicated. You want to look inside that package to find all the rules.

OK. Is it easy to "look inside the package" and where would I look?

Well, a "rpm -ql selinux-policy-targeted" lists a whole bunch of files, mostly all residing under /etc/selinux/targeted/ directory. So you can take a look at what is in there. If that is not enough (ie. if you want to look "inside" the binary modules), you'll probably want to read the corresponding srpm. Use the Source, Luke! ;-)

Btw, your question is about some quite low-level-inside-guts of the SELinux policy. I cannot imagine why you would want to know the detailed relationships between labels, unless you are a SELinux developer. Or is it just curiosity?

I think it's because the doc page said "Access is allowed only between similar types" and I took that to mean that I should look at the type of a process and the type of a file to figure out if something was going to be allowed, if writing a script to do something unusual and hoping for it to work under SELinux.

However, maybe the more useful answer is that because SELinux's error reporting is so thorough and human-readable -- you can convert every error message into a mini-article using audit2allow or sealert, telling you exactly what to do -- that you don't need to code "defensively", you can just run a program, see what errors are logged, and look at the report to see exactly what needs to be changed. This takes some getting used to since SELinux is the only thing I've seen that comes with tools to explain its error messages so helpfully. Everything else, the error messages are usually so obscure that it's easier to code defensively and follow guidelines for what you know *will* work.

HTH, :-) Marko

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 01/07/2012 09:21 PM, Gordon Messmer wrote:

On 01/05/2012 01:36 PM, Bennett Haselton wrote:

...

http://wiki.centos.org/HowTos/SELinux says: "Access is only allowed between similar types, so Apache running as httpd_t can read /var/www/html/index.html of type httpd_sys_content_t."

however the doc doesn't define what "similar types" means.

That is a gross oversimplification. Access is allowed based on a policy, and no "similarity" between types is required.

If you'd like to see what is allowed, you'll have to get the selinux-policy src.rpm and unpack it to examine the source for the policy. It sucks, but as far as I know, no more user-friendly method exists.

...

and the robots.txt file has type file_t: [root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root system_u:object_r:file_t:s0 /var/www/html/robots.txt

but Apache can of course access that file.

If apache can access a mislabeled file, then either SELinux is disabled or in permissive mode. Use "getenforce" to determine which. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

man sesearch

sesearch -A -s httpd_t -C

WIll show you all the allow rules for the apache service.