The Silence of the Anacrons
by Ted Rule
Something that's niggled me for a while are the empty Email messages
generated by Anacron.
This is on FC4 / selinux-policy-strict-1.27.1-2.22
When the machine is left powered overnight, the normal /etc/cron.daily
processes - including logwatch and logrotate - run perfectly happily and
generate appropriate Emails.
By default, logrotate doesn't result in an Email, but for reasons
unrelated to SELinux I have it set to run in debug mode, so my instance
does. The Email from logrotate is effectively 'sent' by /etc/cron.daily
as it wrappers all the output from its child jobs.
In contrast, logwatch sends its own Email independent of Cron's sendmail
child process.
When the machine is depowered overnight and repowered in the morning,
Anacron proceeds to run the various /etc/cron.daily scripts. With
SELinux enforcing, logwatch runs normally, and generates its normal
Email log summary.
However, logrotate's output is never seen, even though it can be seen
from the various timestamps and filenames that logrotate has correctly
run and suitably rotated all the logs.
The overall cron.daily Job launched by Anacron results in an empty
Email, with no body and more particularly no Subject. The mail From
address is set to "Anacron <root@hostname>".
Burrowing around the Anacron source it is apparent that under normal
circumstances it would give the Email a subject of
"Anacron job cron.daily"
Given the behaviour I see, I think the problem is somehow related to
the /etc/cron.daily/* processes not having rights to write to the file
descriptor which is the input to Cron's overall sendmail process.
I've had a look through the SELinux policy to see if I can spot the
difference between the permissions of Jobs launched by Cron and Anacron,
and I'm afraid I can't see where the problem lies; since jobs launched
by either method appear to run as system_crond_t, the difference in
behaviour eludes me.
Can anyone else offer any insight into the problem?
Thanks,
--
Ted Rule
Director, Layer3 Systems Ltd
W: http://www.layer3.co.uk/
17 years
autorelabel and sym links
by Bruno Wolff III
When a file system is relabelled, how are files pointed to by sym links
affected? I can think of several different ways they may be handled, but
I haven't found any clear cut documentation on this subject.
Similarly how does restorecon -R behave? Currently the man page is silent,
but a google search turned up a change log entry suggesting it doesn't
follow sym links.
17 years
fc5: several troubles at my first attempt
by Maxim Britov
I have installed current fc5 by http about week or two ago. It updated from rawhide.
It currently installed on hda2 and it ran from qemu.
I see many avc denied messages in dmesg (repeated 210 times with different pids):
audit(1142439027.188:2): avc: denied { search } for pid=349 comm="pam_console_app" name="var" dev=hda2 ino=210081 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_t:s0 tclass=dir
hda2 here is /
It can't mount /var/spool/squid at boot time. dmesg is:
audit(1142439059.662:212): avc: denied { mounton } for pid=820 comm="mount" name="squid" dev=hda7 ino=261122 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:squid_cache_t:s0 tclass=dir
hda7 here is /var
After booting I can mount it with: # mount /var/spool/squid (/etc/fstab uses default options):
"kjournald starting. Commit interval 5 seconds
EXT3 FS on hda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
SELinux: initialized (dev hda5, type ext3), uses xattr"
I can't switch to strict mode.
I did it by editing /etc/selinux/config and touch /.autorelabel
System can't boot after restarting: many avc denied for init_t, etc.
Where I wrong?
security: 5 users, 5 roles, 1555 types, 68 bools, 1 sens, 256 cats
security: 55 classes, 89189 rules
SELinux: Completing initialization.
SELinux: Setting up existing superblocks.
SELinux: initialized (dev hda2, type ext3), uses xattr
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts
SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts
SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts
SELinux: initialized (dev devpts, type devpts), uses transition SIDs
SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts
SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts
SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
SELinux: initialized (dev proc, type proc), uses genfs_contexts
SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
audit(1142442162.184:2): avc: denied { search } for pid=1 comm="init" name="lib" dev=hda2 ino=775681 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=dir
audit(1142442162.188:3): avc: denied { read } for pid=1 comm="init" name="ld-linux.so.2" dev=hda2 ino=775935 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=lnk_file
audit(1142442162.188:4): avc: denied { execute } for pid=1 comm="init" name="ld-2.4.so" dev=hda2 ino=775682 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:ld_so_t:s0 tclass=file
audit(1142442162.188:5): avc: denied { read } for pid=1 comm="init" name="ld-2.4.so" dev=hda2 ino=775682 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:ld_so_t:s0 tclass=file
SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
audit(1142442163.580:6): avc: denied { sigchld } for pid=1 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=process
audit(1142442169.142:7): avc: denied { execute } for pid=325 comm="udevd" name="udev_run_hotplugd" dev=hda2 ino=775731 scontext=system_u:system_r:udev_t:s0-s0:c0.c255 tcontext=system_u:object_r:lib_t:s0 tclass=file
audit(1142442169.142:8): avc: denied { execute_no_trans } for pid=325 comm="udevd" name="udev_run_hotplugd" dev=hda2 ino=775731 scontext=system_u:system_r:udev_t:s0-s0:c0.c255 tcontext=system_u:object_r:lib_t:s0 tclass=file
audit(1142442171.434:9): avc: denied { search } for pid=364 comm="pam_console_app" name="var" dev=hda2 ino=210081 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_t:s0 tclass=dir
.........
Please excuse me for my engrish :)
--
Maxim Britov
GnuPG KeyID 0x4580A6D66F3DB1FB xmpp:maxim@modum.by icq 198171258
Fingerprint: 4059 B5C5 8985 5A47 8F5A 8623 4580 A6D6 6F3D B1FB
GnuPG-ru Team (http://lists.gnupg.org/mailman/listinfo/gnupg-ru
xmpp:gnupg-ru@conference.jabber.ru)
17 years
Strict policy tweak for homedir_template
by Valdis.Kletnieks＠vt.edu
selinux-policy-strict-2.2.23-15
I couldn't figure out why stuff in ~/.ssh was getting set to
user_home_t rather than user_home_ssh_t. I had to do the following
patch (to make more-specifics come later) and re-run genhomedircon
before restorecon and friends started DTRT...
--- homedir_template.dist 2006-03-15 16:05:28.000000000 -0500
+++ homedir_template 2006-03-15 17:18:02.000000000 -0500
@@ -2,6 +2,7 @@
HOME_ROOT -d system_u:object_r:home_root_t:s0
HOME_ROOT/\.journal <<none>>
HOME_ROOT/lost\+found -d system_u:object_r:lost_found_t:s0
+HOME_DIR/.+ system_u:object_r:ROLE_home_t:s0
HOME_DIR/((www)|(web)|(public_html))(/.+)? system_u:object_r:httpd_ROLE_content_t:s0
HOME_DIR/\.gnupg(/.+)? system_u:object_r:ROLE_gpg_secret_t:s0
HOME_DIR/\.ircmotd -- system_u:object_r:ROLE_irc_home_t:s0
@@ -12,7 +13,6 @@
HOME_DIR/\.ssh(/.*)? system_u:object_r:ROLE_home_ssh_t:s0
HOME_DIR/\.uml(/.*)? system_u:object_r:ROLE_uml_rw_t:s0
HOME_DIR -d system_u:object_r:ROLE_home_dir_t:s0
-HOME_DIR/.+ system_u:object_r:ROLE_home_t:s0
HOME_DIR/\.ICEauthority.* -- system_u:object_r:ROLE_iceauth_home_t:s0
HOME_DIR/\.xauth.* -- system_u:object_r:ROLE_xauth_home_t:s0
HOME_DIR/\.Xauthority.* -- system_u:object_r:ROLE_xauth_home_t:s0
17 years
swapfile is not automatically enabled
by Dawid Gajownik
Hi!
I see these AVC messages when system wants to enable swapfile on boot:
type=AVC msg=audit(1142323714.305:7): avc: denied { getattr } for
pid=1921 comm="fstab-sync" name="swapfile" dev=hda5 ino=881811
scontext=system_u:system_r:updfstab_t tcontext=root:object_r:swapfile_t
tclass=file
type=AVC_PATH msg=audit(1142323714.305:7): path="/var/swapfile"
OS: FC4
selinux-policy-targeted: 1.27.1-2.22
Everything works fine if I boot with `enforcing=0' kernel option. That
is more, default SELinux policy in FC5 does not cause such a problems.
How can I fix it?
Regards,
Dawid
--
^_*
17 years
SELinux and /proc
by Ron Yorston
Testing FC5T3 the other week I wanted to find the arguments that
gdm had used when it started Xnest, so I ran:
ps ax | grep Xnest
This didn't produce the expected response. On further investigation
I found that several processes weren't being listed by 'ps ax' when
run as an ordinary user but were when run as root. Running ps under
strace showed that it was failing to open files in /proc. This was
clearly an SELinux issue, as rebooting with enforcing=0 made the
problem go away.
I raised this in bugzilla:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183387
but the report has been closed as NOTABUG with the response:
This is intended behaviour and part of SELinux with MCS policy.
I'd like this to be reconsidered. I don't think that the targeted
policy should break such long-standing Unix conventions as the
behaviour of 'ps ax'. It's perfectly obvious to a user when they're
running an X server, so having ps or top pretend that they're not
doesn't seem very helpful.
Ron
17 years
selinux apache and mod_python
by Lars Gullik Bjønnes
I am having some difficutlies using different python libs that want to
open priveledged ports on localhost or other hosts. f.ex. smtplib.
What must be done SELinux wise to get this to work?
I get (audit) errors like this:
type=SOCKETCALL msg=audit(1142255739.103:87743): nargs=3 a0=ba1=b7cc90e0 a2=10
type=AVC msg=audit(1142256578.528:87744): avc: denied { name_connect} for pi
d=16624 comm="httpd" dest=25 scontext=root:system_r:httpd_t tcontext=system_u:object_r:smtp_port_t tclass=tcp_socket
type=SYSCALL msg=audit(1142256578.528:87744): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfee0760 a2=3e5114 a3=b7d290c8 items=0 pid=16624 auid=500 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd"
--
Lgb
17 years
postfix high-ports prob
by Holger Burde
Hi;
FC 4 currrent with targeted - up2date & unmodified.
The postfix Policy or some other seems 2 prevent binding postfix to
unpriv Ports > 1023 (10026 in my case). Is this intentional and if why ?
Daemon based Filtering stuff needs those high-ports.
Since after setting setenforce to 0 it works i think i must be policy
related (the system has no source policy - so i didn't dig into that
yet).
Mar 11 14:06:40 proton postfix/master[3413]: fatal: bind 127.0.0.1 port
10026: Permission denied
No avc denies (audit2allow) - strange and not funny .. if its policy
related.
PS I use some of my own RPMs (clamsmtp & anomy ..) with Postfix (FC4) &
Clamav (FC4 extras) which works beside this Port Problem. Since selinux
is part of my security Concept setenforce 0 is no option.
hb
--
--- -- -
Dipl. Inform. H. Burde
EMail : <hburde(a)t-online.de>| <hburde(a)uni-bremen.de>
17 years
