console-kit-domain
by Tom London
Running latest rawhide, targeted/enforcing.
'console-kit-daemon' is running as initrc_t.
I'm getting the following AVC:
type=USER_AVC msg=audit(1169660835.581:34): user pid=2558 uid=81
auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0 msg='avc:
denied { send_msg } for msgtype=method_call
interface=org.freedesktop.ConsoleKit.Manager
member=OpenSessionWithParameters dest=org.freedesktop.ConsoleKit
spid=3363 tpid=3018 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
tcontext=system_u:system_r:initrc_t:s0 tclass=dbus :
exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)'
[root@localhost ~]# ls -lZ /usr/sbin/console*
-rwxr-xr-x root root system_u:object_r:sbin_t
/usr/sbin/console-kit-daemon
[root@localhost ~]#
Should /usr/sbin/console-kit-daemon be xdm_exec_t ?
tom
[Not sure how to BZ this.... ConsoleKit package is not listed in bugzilla.]
--
Tom London
17 years, 3 months
tzdata-update AVC caused by pam_console ?
by Davide Bolcioni
Greetings,
I am investigating the following AVCs
Jan 6 18:12:25 camelot kernel: audit(1168103545.309:4): avc: denied { use }
for pid=2302 comm="tzdata-update" name="tty1" dev=tmpfs ino=1745
scontext=root:system_r:tzdata_t:s0-s0:c0.c255
tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=fd
Jan 6 18:12:25 camelot kernel: audit(1168103545.310:5): avc: denied { use }
for pid=2302 comm="tzdata-update" name="tty1" dev=tmpfs ino=1745
scontext=root:system_r:tzdata_t:s0-s0:c0.c255
tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=fd
which occurred when updating tzdata just after upgrading from Fedora Core 5 to
Fedora Core 6. During the same update I also encountered
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222179
but I did not see the above two lines mentioned (the inode 1745
matched /dev/tty1 at the time). I just tried running tzdata-update from an
xterm and when logged at the console, but the above no longer happens. At
present I have:
$ ls -lZ /dev/tty1
crw--w---- root tty root:object_r:tty_device_t /dev/tty1
so I wonder if the above just got fixed in the meantime or there is some
interaction with pam_console using different labeling from what the policy
expects - I was running in runlevel 1 at the time.
Thank you for your consideration,
Davide Bolcioni
--
There is no place like /home.
17 years, 3 months
anacron under FC6/SELinux/strict
by Ted Rule
I've patched my local FC6 strict policy to accommodate the use of
anacron; as the machine is generally powered off overnight, anacron gets
far more usage than crond. The FC6 strict policy,
selinux-policy-2.4.6-17.fc6.noarch.rpm, appeared to fail to run the
overnight jobs in the correct domains.
Whilst investigating the issue, I noted the following:
crond starts up in crond_t, but seemingly transitions itself to
system_crond_t via setexeccon().
anacron is also started in crond_t, but doesn't bother to call
setexeccon(), and hence remains forever in crond_t.
Under targeted policy only, crond_t is a typealias for system_crond_t
The various auto-transitions to logrotate_t, logwatch_t and so on, are
apparently linked to system_crond_t rather than crond_t. Hence
anacron jobs never transition to system_crond_t, unless the policy is
targeted, in which case anacron is already in system_crond_t by virtue
of the typealias.
The fcron package in Extras appears to have sufficient functionality to
replace both anacron and cron, and also knows about setexeccon(), but I
didn't investigate this further.
The nsarefpolicy contains a separate transition from initrc_t to
system_crond_t for anacron_exec_t, but the latest FC6 policy,
(selinux-policy-2.4.6-17.fc6.noarch.rpm), has both the anacron_exec_t
definition and the alternative transition patched out.
The latest rawhide policy contains some additional fixes for anacron
covering /var/spool/anacron and /var/lock usage, but not the
anacron_exec_t definition or the initrc_t -> system_crond_t transition.
Because the cron.fc already defines a label for /usr/sbin/anacron, I've
manually labelled /usr/sbin/anacron to anacron_exec_t for the present.
Obviously this label will be undone by any /.autorelabel I'm forced to
invoke, until such time as this patch, or an equivalent fix, is
released.
My current patch module, incorporating the cron fixes already in
selinux-policy-2.4.6-21.fc6.noarch.rpm, is as below. The ifdef strict
clause at the end avoids a double definition of the same policy on
targeted where crond_t and system_crond_t are the same thing.
I guess that in an ideal world, anacron itself would be patched to
launch all it's child jobs in system_crond_t, further emulating crond's
behaviour, and thereby avoiding this fixup.
[root@topaz ~]# cat /root/selinux.local/localanacron.fc
# anacrond executable will have:
# label: system_u:object_r:anacron_exec_t
# MLS sensitivity: s0
# MCS categories: <none>
# We cant easily override the /usr/sbin/anacron setting in Fedora
policy, so we create
# a clone binary and label as anacron_exec_t
/usr/sbin/anacrond --
gen_context(system_u:object_r:anacron_exec_t,s0)
/var/lock/subsys/anacron --
gen_context(system_u:object_r:system_crond_lock_t,s0)
/var/spool/anacron(/.*)?
gen_context(system_u:object_r:cron_spool_t,s0)
[root@topaz ~]#
[root@topaz ~]# cat /root/selinux.local/localanacron.te
policy_module(localanacron,0.1.1)
require {
type system_crond_t;
type system_crond_lock_t;
type cron_spool_t;
type crond_var_run_t;
}
########################################
#
# Anacron local policy
#
type anacron_exec_t;
corecmd_executable_file(anacron_exec_t)
# anacron transitions directly to system_crond_t,
# rather than crond_t because it doesnt currently
# perform a setexeccon internally
init_daemon_domain(system_crond_t,anacron_exec_t)
# Allow anacron to update spool files in /var/spool/anacron
allow system_crond_t cron_spool_t:file create_file_perms;
# This is to handle creation of files in /var/lock directory. (anacron)
allow system_crond_t system_crond_lock_t:file create_file_perms;
files_lock_filetrans(system_crond_t,system_crond_lock_t,file)
# Allow anacron to write to /var/run/anacron.pid
ifdef(`strict_policy',`
allow system_crond_t crond_var_run_t:file create_file_perms;
files_pid_filetrans(system_crond_t,crond_var_run_t,file)
')
[root@topaz ~]#
--
Ted Rule
Director, Layer3 Systems Ltd
W: http://www.layer3.co.uk/
17 years, 3 months
Cron mail problem with FC6/strict
by Ted Rule
A little while ago, I found that anacron wasn't running correctly under
FC6/strict, which led to me add a temporary fixup .te for its operation.
Once I had that in place, I finally received the cron.daily and logwatch
Emails every day shortly after bootup.
With that in place, I recently took to leaving the machine powered
overnight, which of course led to all the Cron jobs running via crond
instead of anacron.
Oddly, I noticed that the logwatch Email arrived, but NOT the cron.daily
summary Email.
Looking further, I found this odd avc:
Jan 21 21:29:51 topaz kernel: audit(1169414991.423:988): avc: denied
{ entrypoint } for pid=4891 comm="crond" name="sendmail.sendmail"
dev=hda6 ino=1313020
scontext=system_u:system_r:system_crond_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file
i.e. the crond child process running in system_crond_t was apparently
unable to run sendmail.
Just to be curious, I added this permission:
auditallow system_crond_t sendmail_exec_t:file execute
and saw this:
Jan 21 21:30:51 topaz kernel: audit(1169415051.521:993): avc: granted
{ execute } for pid=4909 comm="crond" name="sendmail.sendmail" dev=hda6
ino=1313020 scontext=system_u:system_r:crond_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file
Jan 21 21:30:51 topaz kernel: audit(1169415051.521:994): avc: denied
{ entrypoint } for pid=4909 comm="crond" name="sendmail.sendmail"
dev=hda6 ino=1313020
i.e. crond was apparently allowed to execute sendmail but got caught
with the 'entrypoint' denial slightly later on.
As an added test, I created a per-minute Cron Job which itself
invoked /bin/mail which in turn called sendmail and a few invocations of
sleep (the sleeps just to make it slightly easier to read the process
list changes).
Jan 21 21:31:11 topaz kernel: audit(1169415071.651:996): avc: granted
{ execute } for pid=4938 comm="mail" name="sendmail.sendmail" dev=hda6
ino=1313020 scontext=system_u:system_r:system_crond_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file
Jan 21 21:31:11 topaz kernel: audit(1169415071.651:997): avc: granted
{ read execute } for pid=4938 comm="sendmail" name="sendmail.sendmail"
dev=hda6 ino=1313020
scontext=system_u:system_r:system_crond_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file
Jan 21 21:31:51 topaz kernel: audit(1169415111.704:999): avc: granted
{ execute } for pid=4947 comm="crond" name="sendmail.sendmail" dev=hda6
ino=1313020 scontext=system_u:system_r:crond_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file
Jan 21 21:31:51 topaz kernel: audit(1169415111.704:1000): avc: denied
{ entrypoint } for pid=4947 comm="crond" name="sendmail.sendmail"
dev=hda6 ino=1313020
scontext=system_u:system_r:system_crond_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file
i.e. the call the sendmail from system_crond_t within the Cron job by
something other than the crond binary itself worked Ok, but when crond
tried to invoke, it just sulked.
If I went to permissive mode the log was filled with avc's indicating
that crond's direct invocation of sendmail failed to transition to
system_mail_t, even though these two interface calls appear to exist in
the policy:
mta_send_mail(crond_t)
mta_send_mail(system_crond_t)
For both anacron and crond launched invocations of cron.daily/0logwatch,
of course, logwatch itself invokes sendmail from logwatch_t, so the
problem doesn't arise.
I'm currently using selinux-policy-strict-2.4.6-27
I also tried adding this permission:
allow system_crond_t sendmail_exec_t:file entrypoint
but this didn't really help; crond:system_crond_t stubbornly refused to
transition to system_mail_t.
Since all the invocations from within Jobs running as system_crond_t and
also from anacron running as system_crond_t invoked sendmail Ok, my
presumption is that there's something in crond's own use of libselinux
which is confusing matters and preventing Email's being created.
Looking at the policy source a little bit more,
mta_send_mail() calls domain_auto_trans() which in turn calls
domain_trans().
Way back in FC4 policy, I can see that domain_trans()'s definition
contains an entry that suggests I actually need to add
allow system_mail_t sendmail_exec_t:file entrypoint
since the entrypoint permission appears to take the child_domain's
type as its first parameter, (which itself implies that the log entry is
slightly awry, just to be confusing...):
domain_trans(parent_domain, program_type, child_domain)
...
allow $3 $2:file entrypoint;
The FC6 policy source seems to have no automatic entrypoint permission
within the domain_trans() definition but does have the
domain_entry_file() interface.
Just for fun, therefore, I tried adding this:
domain_entry_file(system_mail_t, sendmail_exec_t)
All to no avail, I'm afraid; I continue to be unable to get crond to
directly execute sendmail.
Can anyone enlighten me, please?
--
Ted Rule
Director, Layer3 Systems Ltd
W: http://www.layer3.co.uk/
--
Ted Rule
Director, Layer3 Systems Ltd
W: http://www.layer3.co.uk/
17 years, 3 months
Re: Worrying AVC messages
by Anne Wilson
On Monday 22 January 2007 19:40, Stephen Smalley wrote:
> > type=AVC msg=audit(1162463326.809:49): avc: denied { search } for
> > pid=4186 comm="postmap" name="nscd" dev=hdb1 ino=195773
> > scontext=user_u:system_r:postfix_map_t:s0
> > tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir
> > type=SYSCALL msg=audit(1162463326.809:49): arch=40000003 syscall=102
> > success=no exit=-2 a0=3 a1=bf915688 a2=67eff4 a3=4 items=0 ppid=4147
> > pid=4186 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> > tty=pts5 comm="postmap" exe="/usr/sbin/postmap"
> > subj=user_u:system_r:postfix_map_t:s0 key=(null)
>
> Yes, that shows the security contexts of the source (process) and the
> target (in this case, a directory). audit2allow will turn those
> messages into allow rules, e.g.
> su -
> audit2allow -a -M local
> semodule -i local.pp
>
After reading the man pages I find that I'm no wiser as to what this is doing.
I understand the first and last lines, but could you explain how you build
the audit2allow line, and what it actually does?
Thanks
Anne
17 years, 3 months
selinux and oracle
by bastard operater
I have a RHEL4U4 server that will become an Oracle 10gR2 server in three
weeks. Almost all of the documentation I have seen about installing oracle
on a selinux enabled server says to turn off selinux. Only 1 document said
that oracle and selinux can function together. So can oracle and selinux
play nice or do I have to turn it off?
Thanks,
Adam
_________________________________________________________________
Find sales, coupons, and free shipping, all in one place! MSN Shopping
Sales & Deals
http://shopping.msn.com/content/shp/?ctid=198,ptnrid=176,ptnrdata=200639
17 years, 3 months
Re: Worrying AVC messages
by Anne Wilson
On Monday 22 January 2007 19:40, Stephen Smalley wrote:
> On Mon, 2007-01-22 at 18:59 +0000, Anne Wilson wrote:
> > On Monday 22 January 2007 14:49, you wrote:
> >
> > Hi, Stephen. I'm very new to all this, so bear with me if I don't give
> > you the right info first try :-)
>
> Why take discussion off-list?
>
Sorry - not intentional. A new folder in KMail, and I forgot to set up
Mailing List Management.
> > > You don't seem to have included the scontext, tcontext, and tclass
> > > information, which is the real basis for the permission denial.
> > >
> > > You can also get supplemental information about each avc denial by
> > > enabling system call auditing. Requires installing "audit" and adding
> > > at least one audit rule to enable collection of the full audit context.
> > > This will provide you with information like the system call number and
> > > arguments, the path that has been looked up, etc.
> >
> > I have audit.log and I get logwatch messages, so I think audit is working
> > properly. Where do I look to see if rules have been made? They would
> > probably be defaults, as I'm sure I haven't made any myself.
>
> /sbin/auditctl -l will list any rules. auditctl man page will show you
> some examples of rules, which you can apply manually via auditctl or by
> putting into /etc/audit/audit.rules and re-starting auditd. Any rule
> will suffice, as the goal is just to get the audit system to start
> collecting information for use when an avc message happens; it used to
> always do that proactively, but that caused performance issues, so they
> disabled it when there are no audit rules in place.
>
Fine. I'll see what I can do with this.
> > Is this the kind of info you need?
> >
> > type=AVC msg=audit(1162463326.809:49): avc: denied { search } for
> > pid=4186 comm="postmap" name="nscd" dev=hdb1 ino=195773
> > scontext=user_u:system_r:postfix_map_t:s0
> > tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir
> > type=SYSCALL msg=audit(1162463326.809:49): arch=40000003 syscall=102
> > success=no exit=-2 a0=3 a1=bf915688 a2=67eff4 a3=4 items=0 ppid=4147
> > pid=4186 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> > tty=pts5 comm="postmap" exe="/usr/sbin/postmap"
> > subj=user_u:system_r:postfix_map_t:s0 key=(null)
>
> Yes, that shows the security contexts of the source (process) and the
> target (in this case, a directory). audit2allow will turn those
> messages into allow rules, e.g.
> su -
> audit2allow -a -M local
> semodule -i local.pp
>
Examples are always helpful :-)
> > type=AVC msg=audit(1169487905.785:178): avc: denied { read } for
> > pid=2965 comm="hald-addon-stor" name="hdc" dev=tmpfs ino=7065
> > scontext=system_u:system_r:hald_t:s0
> > tcontext=system_u:object_r:device_t:s0 tclass=blk_file
> > type=SYSCALL msg=audit(1169487905.785:178): arch=40000003 syscall=5
> > success=yes exit=4 a0=96e1ac6 a1=8880 a2=0 a3=8880 items=0 ppid=2940
> > pid=2965 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> > fsgid=0 tty=(none) comm="hald-addon-stor"
> > exe="/usr/libexec/hald-addon-storage" subj=system_u:system_r:hald_t:s0
> > key=(null)
>
> Question on this one is why this device node has a generic type
> (device_t) rather than a specific one (e.g. removable_device_t).
>
I suspect that this is my video capture card, a pci card for use with an
analogue camcorder. I had been trying to write udev rules to track video0
and video1, so that webcam and camcorder capture could always be found. The
device is listed currently under video1. Udevinfo doesn't walk the sys tree
for this card, the way it does for the webcam. Perhaps that's part of the
puzzle?
> > type=AVC msg=audit(1169489443.261:186): avc: denied { read } for
> > pid=4482 comm="smartd" name="hda" dev=tmpfs ino=879
> > scontext=system_u:system_r:fsdaemon_t:s0
> > tcontext=system_u:object_r:device_t:s0 tclass=blk_file
> > type=SYSCALL msg=audit(1169489443.261:186): arch=40000003 syscall=5
> > success=yes exit=3 a0=99c60a0 a1=800 a2=c3c490 a3=c42cae items=0 ppid=1
> > pid=4482 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> > fsgid=0 tty=(none) comm="smartd" exe="/usr/sbin/smartd"
> > subj=system_u:system_r:fsdaemon_t:s0 key=(null)
>
> Likewise.
>
This I don't understand. I've seen messages like this for hdb as well. They
are standard hdds.
> > > audit2allow can be used to generate a local policy module to allow
> > > permissions as appropriate; see its man page and the Fedora SELinux
> > > FAQ.
> >
Thanks for the help so far. I'll catch up on the reading.
Anne
17 years, 3 months
Selinux, Oracle, DBD::Oracle, RHEL5B2
by Thomas J. Baker
I'm trying to set up a a mod_perl/oracle website on an RHEL5B2 system. I
installed the oracle-xe-client rpm, DBD::Oracle, etc. Almost got
everything working except for this selinux problem (http log error):
[Thu Jan 18 14:01:31 2007] [error] [client xxx] install_driver(Oracle)
failed: Can't load
'/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: libclntsh.so.10.1: cannot enable executable stack as shared object requires: Permission denied at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/DynaLoader.pm line 230.\n at (eval 11) line 3\nCompilation failed in require at (eval 11) line 3.\nPerhaps a required shared library or dll isn't installed where expected\n at /web1/perl/Lib/Layout2/Core/Initializer.pm line 191\n\t(in cleanup) Can't call method "disconnect" on an undefined value at /web1/perl/Lib/Layout2/Core/Initializer.pm line 206.\n
I've tried turning off execstack on the affected oracle shared libs but
that didn't work. First I turned it off on libclntsh.so.10.1 but got the
same error about libnnz10.so so I turned it off on that. Then I got
[Thu Jan 18 14:06:29 2007] [error] [client xxx] install_driver(Oracle)
failed: Can't load
'/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: /usr/lib/oracle/xe/app/oracle/product/10.2.0/client/lib/libnnz10.so: cannot restore segment prot after reloc: Permission denied at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/DynaLoader.pm line 230.\n at (eval 11) line 3\nCompilation failed in require at (eval 11) line 3.\nPerhaps a required shared library or dll isn't installed where expected\n at /web1/perl/Lib/Layout2/Core/Initializer.pm line 191\n\t(in cleanup) Can't call method "disconnect" on an undefined value at /web1/perl/Lib/Layout2/Core/Initializer.pm line 206.\n
Turning on allow_exec{mem,mod,heap} didn't help. I should add that
turning off enforcing makes everything work.
Is there any type I can label the oracle libs so this works?
Thanks,
tjb
--
=======================================================================
| Thomas Baker email: tjb(a)unh.edu |
| Systems Programmer |
| Research Computing Center voice: (603) 862-4490 |
| University of New Hampshire fax: (603) 862-1761 |
| 332 Morse Hall |
| Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb |
=======================================================================
17 years, 3 months
Worrying AVC messages
by Anne Wilson
I'm seeing a lot of AVC message, a sample of which is
type=AVC msg=audit(1162463326.809:49): avc: denied { search } for pid=4186
comm="postmap" name="nscd" dev=hdb1 ino=195773
type=AVC msg=audit(1162483288.034:31): avc: denied { write } for pid=5804
comm="ip" name="[23145]" dev=pipefs ino=23145
type=AVC msg=audit(1162483738.762:39): avc: denied { write } for pid=7191
comm="ip" name="[27659]" dev=pipefs ino=27659
type=AVC msg=audit(1169284673.188:58): avc: denied { ioctl } for pid=4212
comm="smartd" name="hda" dev=tmpfs ino=879
type=AVC msg=audit(1162495544.436:62): avc: denied { write } for pid=28024
comm="setfiles" name="[120832]" dev=pipefs ino=120832
type=AVC_PATH msg=audit(1169310171.523:150): path="/dev/bus/usb/001/004"
type=AVC msg=audit(1169310172.778:151): avc: denied { read } for pid=2996
comm="hald-addon-stor" name="hdd" dev=tmpfs ino=7431
I don't really understand what is going on. 'postmap' to me implies postfix,
which seems odd.
There are many such messages about smartd. This is something I'd want to be
working. Why is this blocked? Can/Should I enable it? How?
I looked at /dev/bus/usb/001/004 but I can't tell what this is. I'm guessing
that it's a card-reader, but it's sheer guesswork.
I'd be glad of any hints. SELinux hasn't really caused me any problems up to
now, but one of my projects, which I'll address in a later thread, may be
being blocked, so I need to start to understand more.
Thanks
Anne
17 years, 3 months
