Re: Denied { search } mingetty and can't log in
by Emeric Maschino
Hi,
> Just to let you know that the above AVCs have been reported as bug
> #178747, #178748, #178789, #178750 and #178753. It seems they're all due
> to an ia64 specific issue (details in bug #178747). I don't know if my
> original problem in enforcing mode with mingetty is also concerned by
> this issue. Today kernel should provide a workaround for the AVCs in
> permissive mode. I'll test it and let you know the result.
With kernel 2.6.15-1.1878_FC5, execmod checks are disabled, so I'm no
more getting the corresponding AVCs. Furthermore, I'm now able to start
in enforcing mode (the problem with mingetty was also solved). However,
from the audit.log file, I'm still getting denied read and search AVCs,
mainly due to irqbalance and hald:
type=AVC msg=audit(1138388575.636:9): avc: denied { read } for
pid=1946 comm="irqbalance" name="mtab" dev=dm-0 ino=1899143
scontext=system_u:system_r:irqbalance_t:s0
tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file
type=SYSCALL msg=audit(1138388575.636:9): arch=c0000032 syscall=1028
success=no
exit=13 a0=20000008002ae8d0 a1=0 a2=1b6 a3=558281 items=1 pid=1946
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="irqbalance" exe="/usr/sbin/irqbalance"
type=AVC msg=audit(1138388575.636:10): avc: denied { read } for
pid=1946 comm="irqbalance" name="fstab" dev=dm-0 ino=1901326
scontext=system_u:system_r:irqbalance_t:s0
tcontext=system_u:object_r:etc_t:s0 tclass=file
type=SYSCALL msg=audit(1138388575.636:10): arch=c0000032 syscall=1028
success=no exit=13 a0=20000008002ae938 a1=0 a2=1b6 a3=558281 items=1
pid=1946 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 comm="irqbalance" exe="/usr/sbin/irqbalance"
type=AVC msg=audit(1138385008.409:11): avc: denied { search } for
pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177
scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:boot_t:s0 tclass=dir
type=AVC msg=audit(1138385008.477:12): avc: denied { search } for
pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177
scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:boot_t:s0 tclass=dir
type=AVC msg=audit(1138385008.593:13): avc: denied { search } for
pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177
scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:boot_t:s0 tclass=dir
type=AVC msg=audit(1138385008.677:14): avc: denied { search } for
pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177
scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:boot_t:s0 tclass=dir
type=AVC msg=audit(1138385008.733:15): avc: denied { search } for
pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177
scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:boot_t:s0 tclass=dir
type=AVC msg=audit(1138385012.697:17): avc: denied { search } for
pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177
scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:boot_t:s0 tclass=dir
Cheers,
M
18 years, 3 months
Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16
by G Jahchan
I have been desperately trying to get selinux strict policy to work on my
laptop to no avail. I have been using a strict policy in enforcing mode for a
long time, but since I upgraded to the kernel / selinux versions listed below,
when in enforcing mode, the policy causes authentication to fail from the
console (my default runlevel is 3).
Even though I have the following statements in my custom.te under
/etc/selinux/strict/src/policy/domains/misc/
allow kernel_t sysadm_t:process transition;
allow kernel_t sysadm_tty_device_t:chr_file { relabelfrom relabelto };
allow sysadm_t sysadm_t:process transition;
I keep getting corresponding 'avc: denied' events in the audit log.
Kernel auditing is enabled at boot time (audit=1 kernel switch) and the audit
daemon is set to run at boot time.
I am using:
kernel-2.6.14-1.1653_FC4
selinux-policy-strict-sources-1.27.1-2.16
How can I go about fixing this issue?
18 years, 3 months
user mapping
by Thorsten Scherf
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
general question: I have a Unix user called "foo" which I would like to
map to the SELinux User Identity "bar_u". In which file must I define
this mapping, so that every time the user "foo" logs in, the context is
set to "bar_u:[user_r_user_t]"?!
Thanks,
Thorsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFD3786wfkoLTuSgLsRAnOeAKD5oEejeLDKy2f3jsxjnty8uB7abACg8Ysk
VNN2B9+3sGwpjGnmf3utQx0=
=eW75
-----END PGP SIGNATURE-----
18 years, 3 months
Nagios nrpe and sudo
by Martin Ebourne
Hi,
I'm getting AVC denied with a nagios nrpe script which needs to sudo.
The script works fine without selinux. I'm on FC4.
nrpe is the remote execution feature in nagios. It runs under xinetd and
accepts incoming commands. It then runs scripts to fetch results. My
script to get harddisk smart attributes looks like so:
==========
#!/bin/sh
device="$1"
attribute="$2"
#id
sudo /usr/sbin/smartctl -A $device | perl -ne 'm{^\s*\Q'"$attribute"'\E
\s} && split && print "$_[9]"'
==========
During execution of the script id returns:
uid=173(nagios) gid=173(nagios) context=system_u:system_r:inetd_t
But I get this avc denial:
type=AVC msg=audit(1138482709.249:31780): avc: denied { entrypoint }
for pid=11537 comm="sudo" name="sesh" dev=dm-0 ino=442643
scontext=root:system_r:amanda_t tcontext=system_u:object_r:shell_exec_t
tclass=file
Seems reasonable. There don't seem to be any booleans for nrpe but there
is inetd_child_disable_trans. With that set id gives:
uid=173(nagios) gid=173(nagios) context=root:system_r:inetd_t
But I get the same denial:
type=AVC msg=audit(1138485617.391:32037): avc: denied { entrypoint }
for pid=14228 comm="sudo" name="sesh" dev=dm-0 ino=442643
scontext=root:system_r:amanda_t tcontext=system_u:object_r:shell_exec_t
tclass=file
I've no idea what amanda_t has got to do with any of this. Am I missing
something obvious? It seems to be running in the new context, but still
be protected. The inetd_child_disable_trans is described in
system-config-securitylevel as "Disable SELinux protection for inetd
child daemons", which is what I seem to need.
I also notice that the current policy has some nrpe stuff in it, but
that doesn't ever seem to take effect. Is this incomplete, or broken?
Cheers,
Martin.
18 years, 3 months
SELinux Wiki is open for business...
by Daniel J Walsh
www.fedoraproject.org/wiki/SELinux is open. If you want to make
changes to these pages and add your own content you
need to make a new account and to send kwade(a)redhat.com a request to get
added to EditGroup or ask on on #fedora-websites on freenode, if they
want faster service
I am attempting to dump some information there, also.
Any input is appreciated.
Dan
18 years, 3 months
ANN: Setools-2.3 release
by Kevin Carr
Setools-2.3 is now available on the Tresys Technology website.
http://tresys.com/selinux/selinux_policy_tools.shtml
This version adds MLS and OCONS to apol and seinfo as well as some other
smaller changes throughout the tools.
Here is the detailed changelog.
apol:
added new MLS components tab for sensitivities,
levels, and categories.
Changed users tab to support ranges and default
levels.
added range transition tab for searching range
Transition rules.
added new tab for network context components.
added new tab for file system context components.
libapol:
added binpol support for MLS, network contexts,
and file system contexts.
seinfo:
added command line options for MLS components.
added command line options for network contexts
and file system contexts.
sesearch:
added command line option for searching for rules
by conditional boolean name.
seaudit:
added new column in the log view for the 'comm'
field found in auditd log files.
added filters for the 'comm' field and 'message'
field.
manpages:
added manpages for all tools.
Kevin Carr
Tresys Technology
410.290.1411 x137
18 years, 3 months
Re: Spamassassin emails have wrong perms -- CC'ed to selinux list]]
by Justin Willmert
Justin Willmert wrote:
> Paul Howarth wrote:
>> On Sun, 2006-01-29 at 22:52 -0600, Justin Willmert wrote:
>>> Ivan Gyurdiev wrote:
>>>>> I'm cc-ing this to the fedora-selinux-list. I think some of the
>>>>> problems may be applicable there.
>>>>>
>>>>> OK, after some more testing, when I disable SELinux, many of the
>>>>> errors go away. First of all, I get rid of the error message
>>>>> saying user can not be found and with it the 'still running as
>>>>> root' error. Second, it is able to access the bayes_journal file
>>>>> (as long as normal unix permissions are right, which I've figured
>>>>> out). So I guess the problem is an SELinux issue which I can't
>>>>> solve. I'd attach some avc error messages, but I can't seem to
>>>>> find any. I've looked in maillog, secure, and messages, but nothing.
>>>> Have you looked in the audit log, where all such messages are
>>>> usually found ?
>>>> /var/log/audit.log
>>>>
>>> Below is what showed up in audit/audit.log when I sent a message
>>> through
>>> spamassassin. I'm _*really*_ rusty on SELinux...it's the one thing I
>>> have to deal with quite often that I haven't been able to learn how to
>>> use...it's so foreign to me. I've never looked in audit.log before: the
>>> avc messages used to show up in messages, but now as far back as my
>>> logs
>>> go, I don't have a single avc message. This all looks like jibberish to
>>> me, so I need your guy's help.
>>>
>>> Thanks,
>>> Justin
>>>
>>> type=AVC msg=audit(1138596151.681:104174): avc: denied {
>>> name_connect } for pid=23796 comm="spamd" dest=389
>>> scontext=root:system_r:spamd_t
>>> tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket
>>> < clipped >
>>
>> Are you using LDAP for authentication or to handle mail accounts?
>>
>> Paul.
> No, I am not using LDAP in spamassassin itself (there are ldap
> arguments to spamd and I'm not using those), but my system uses LDAP
> authentication through nsswitch/pam (whatever the distinction is).
> Does spamd need to know my ldap server's information?
>
> I believe I found a temporary work around for the bayes files: I put
> them in a non-standard location (/etc/mail/bayes/) because I wanted a
> system-wide database (some users don't get enough spam to warrant
> their own database). I found if I set /etc/mail/bayes/ to
> user_home_dir_t and /etc/mail/bayes/* to user_home_t that the denied
> messages for files are gone (if I'm reading the logs right). I don't
> see the file denial messages in the log output I put above, but they
> are in audit.log and in the latest test, they aren't there so I'm
> hoping I'm looking into all of this right. If you want me to confirm
> all of this, I can reset the directory context and do some tests, then
> set up the directory context again and compare that result, somebody
> just has to ask.
> Now I've just got to solve the LDAP messages. I'll try to look into
> this a bit, but I'm probably going to need the help, so thanks to all
> those who take time to reply.
>
> Justin
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
I've got a question about how SELinux works underneath. I'm doing a lot
of speculating based on the few things I think I know, so correct me
when I'm wrong.
When SpamAssassin wants to get the user information, it probably uses a
system call that is controlled through /etc/nsswitch.conf (I've seen the
call before, but can't think of it off the top of my head). That in turn
would connect to my LDAP server and authenticate the user and download
its profile information. The nsswitch libraries would be in
SpamAssassin's process space (if I understand linux programming
correctly), so that would mean that if SpamAssassin is under an SELinux
context, then the nsswitch libraries would be too. Would this be where
I'm getting denied messages for ldap_port_t messages from?
If I've thought this through correctly and this is a problem, would
somebody tell me so that I can post a bugzilla report? I'll search
bugzilla later to make sure that it's not already in there (I've got to
go to school so I don't really have time to do it right now).
Thanks to all those who've helped!
Justin
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
18 years, 3 months
mono (beagle) + execmem
by dragoran
it seems that beagle/mono requires execmem but this is disabled in the
policy for them?
is this a known bug or should I fill it?
18 years, 3 months
More changes to NetworkManager for WPA... (yea!)
by Tom London
Running today's rawhide, targeted/enforcing.
The new kernel and NM supports WPA. Works in permissive mode.
Seems to want:
allow NetworkManager_t self:unix_dgram_socket sendto;
allow NetworkManager_t tmp_t:dir remove_name;
allow NetworkManager_t tmp_t:sock_file unlink;
allow NetworkManager_t var_run_t:dir create;
allow NetworkManager_t var_run_t:sock_file setattr;
----
type=PATH msg=audit(01/31/2006 07:17:14.277:45) : item=0 flags=parent
inode=2777160 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00
type=SOCKETCALL msg=audit(01/31/2006 07:17:14.277:45) : nargs=3 a0=3
a1=bfd8f0fe a2=6e
type=SOCKADDR msg=audit(01/31/2006 07:17:14.277:45) : saddr=local
/var/run/wpa_supplicant-global
type=SYSCALL msg=audit(01/31/2006 07:17:14.277:45) : arch=i386
syscall=socketcall(bind) success=yes exit=0 a0=2 a1=bfd8f0e0 a2=3
a3=8af7020 items=1 pid=3138 auid=unknown(4294967295) uid=root gid=root
euid=root suid=root fsuid=root egid=root sgid=root fsgid=root
comm=wpa_supplicant exe=/usr/sbin/wpa_supplicant
type=AVC msg=audit(01/31/2006 07:17:14.277:45) : avc: denied {
create } for pid=3138 comm=wpa_supplicant name=wpa_supplicant-global
scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file
----
type=PATH msg=audit(01/31/2006 07:17:15.281:46) : item=0 flags=parent
inode=980161 dev=fd:00 mode=dir,sticky,777 ouid=root ogid=root
rdev=00:00
type=SOCKETCALL msg=audit(01/31/2006 07:17:15.281:46) : nargs=3 a0=12
a1=810f9ac a2=6e
type=SOCKADDR msg=audit(01/31/2006 07:17:15.281:46) : saddr=local
/tmp/wpa_ctrl_2606-1
type=SYSCALL msg=audit(01/31/2006 07:17:15.281:46) : arch=i386
syscall=socketcall(bind) success=yes exit=0 a0=2 a1=b7579240 a2=1
a3=810f9a8 items=1 pid=2615 auid=unknown(4294967295) uid=root gid=root
euid=root suid=root fsuid=root egid=root sgid=root fsgid=root
comm=NetworkManager exe=/usr/sbin/NetworkManager
type=AVC msg=audit(01/31/2006 07:17:15.281:46) : avc: denied {
create } for pid=2615 comm=NetworkManager name=wpa_ctrl_2606-1
scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file
type=AVC msg=audit(01/31/2006 07:17:15.281:46) : avc: denied {
add_name } for pid=2615 comm=NetworkManager name=wpa_ctrl_2606-1
scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=AVC msg=audit(01/31/2006 07:17:15.281:46) : avc: denied { write
} for pid=2615 comm=NetworkManager name=tmp dev=dm-0 ino=980161
scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=AVC msg=audit(01/31/2006 07:17:15.281:46) : avc: denied {
search } for pid=2615 comm=NetworkManager name=tmp dev=dm-0
ino=980161 scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=dir
----
type=PATH msg=audit(01/31/2006 07:17:15.281:47) : item=0 flags=follow
inode=2778180 dev=fd:00 mode=socket,755 ouid=root ogid=root rdev=00:00
type=SOCKETCALL msg=audit(01/31/2006 07:17:15.281:47) : nargs=3 a0=12
a1=810fa1a a2=6e
type=SOCKADDR msg=audit(01/31/2006 07:17:15.281:47) : saddr=local
/var/run/wpa_supplicant-global
type=AVC_PATH msg=audit(01/31/2006 07:17:15.281:47) :
path=/var/run/wpa_supplicant-global
type=SYSCALL msg=audit(01/31/2006 07:17:15.281:47) : arch=i386
syscall=socketcall(connect) success=yes exit=0 a0=3 a1=b7579240 a2=1
a3=0 items=1 pid=2615 auid=unknown(4294967295) uid=root gid=root
euid=root suid=root fsuid=root egid=root sgid=root fsgid=root
comm=NetworkManager exe=/usr/sbin/NetworkManager
type=AVC msg=audit(01/31/2006 07:17:15.281:47) : avc: denied {
sendto } for pid=2615 comm=NetworkManager name=wpa_supplicant-global
scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:system_r:NetworkManager_t:s0
tclass=unix_dgram_socket
type=AVC msg=audit(01/31/2006 07:17:15.281:47) : avc: denied { write
} for pid=2615 comm=NetworkManager name=wpa_supplicant-global
dev=dm-0 ino=2778180 scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file
----
type=PATH msg=audit(01/31/2006 07:17:15.309:48) : item=0
name=/var/run/wpa_supplicant flags=parent inode=2777160 dev=fd:00
mode=dir,755 ouid=root ogid=root rdev=00:00
type=CWD msg=audit(01/31/2006 07:17:15.309:48) : cwd=/
type=SYSCALL msg=audit(01/31/2006 07:17:15.309:48) : arch=i386
syscall=mkdir success=yes exit=0 a0=8af7aa8 a1=1f8 a2=8af7958
a3=8af7958 items=1 pid=3138 auid=unknown(4294967295) uid=root gid=root
euid=root suid=root fsuid=root egid=root sgid=root fsgid=root
comm=wpa_supplicant exe=/usr/sbin/wpa_supplicant
type=AVC msg=audit(01/31/2006 07:17:15.309:48) : avc: denied {
create } for pid=3138 comm=wpa_supplicant name=wpa_supplicant
scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:var_run_t:s0 tclass=dir
----
type=PATH msg=audit(01/31/2006 07:17:15.465:49) : item=0
name=/var/run/wpa_supplicant/eth1 flags=follow inode=3628151 dev=fd:00
mode=socket,755 ouid=root ogid=root rdev=00:00
type=CWD msg=audit(01/31/2006 07:17:15.465:49) : cwd=/
type=SYSCALL msg=audit(01/31/2006 07:17:15.465:49) : arch=i386
syscall=chmod success=yes exit=0 a0=8b00e68 a1=1f8 a2=8b00e68
a3=8af7958 items=1 pid=3138 auid=unknown(4294967295) uid=root gid=root
euid=root suid=root fsuid=root egid=root sgid=root fsgid=root
comm=wpa_supplicant exe=/usr/sbin/wpa_supplicant
type=AVC msg=audit(01/31/2006 07:17:15.465:49) : avc: denied {
setattr } for pid=3138 comm=wpa_supplicant name=eth1 dev=dm-0
ino=3628151 scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file
----
type=AVC msg=audit(01/31/2006 07:17:15.465:50) : avc: denied { write
} for pid=3138 comm=wpa_supplicant name=wpa_ctrl_2606-1 dev=dm-0
ino=980237 scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file
----
type=PATH msg=audit(01/31/2006 07:17:15.465:51) : item=0
name=/tmp/wpa_ctrl_2606-1 flags=parent inode=980161 dev=fd:00
mode=dir,sticky,777 ouid=root ogid=root rdev=00:00
type=CWD msg=audit(01/31/2006 07:17:15.465:51) : cwd=/
type=SYSCALL msg=audit(01/31/2006 07:17:15.465:51) : arch=i386
syscall=unlink success=yes exit=0 a0=810f9ae a1=1 a2=810f9a8
a3=81084b0 items=1 pid=2615 auid=unknown(4294967295) uid=root gid=root
euid=root suid=root fsuid=root egid=root sgid=root fsgid=root
comm=NetworkManager exe=/usr/sbin/NetworkManager
type=AVC msg=audit(01/31/2006 07:17:15.465:51) : avc: denied {
unlink } for pid=2615 comm=NetworkManager name=wpa_ctrl_2606-1
dev=dm-0 ino=980237 scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file
type=AVC msg=audit(01/31/2006 07:17:15.465:51) : avc: denied {
remove_name } for pid=2615 comm=NetworkManager name=wpa_ctrl_2606-1
dev=dm-0 ino=980237 scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=dir
----
type=PATH msg=audit(01/31/2006 07:17:15.465:50) : item=0 flags=follow
inode=980237 dev=fd:00 mode=socket,755 ouid=root ogid=root rdev=00:00
type=SOCKETCALL msg=audit(01/31/2006 07:17:15.465:50) : nargs=6 a0=3
a1=8af7150 a2=3 a3=0 a4=bfd8f0b6 a5=17
type=SOCKADDR msg=audit(01/31/2006 07:17:15.465:50) : saddr=local
/tmp/wpa_ctrl_2606-1
type=SYSCALL msg=audit(01/31/2006 07:17:15.465:50) : arch=i386
syscall=socketcall(sendto) success=yes exit=3 a0=b a1=bfd8ef80
a2=bfd8efc4 a3=0 items=1 pid=3138 auid=unknown(4294967295) uid=root
gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root
comm=wpa_supplicant exe=/usr/sbin/wpa_supplicant
--
Tom London
18 years, 3 months
Re: su, context(selinux?) 2nd prompt
by Rex Dieter
Maciej Żenczykowski wrote:
> Weird, I'm not seeing this...
Are using an selinux-enabled CentOS 4.2 (or RHEL4U2) box?
-- Rex
> On Mon, 23 Jan 2006, Rex Dieter wrote:
>
>> With a recent update of CentOS4, su's behavior has changed, in that after
>> prompting for password, also prompts for (selinux?) context. I'm seeing
>> something like:
>> $ su
>> Password:
>> Your default context is root:system_r:unconfined_t.
>>
>> Do you want to choose a different one? [n]
>>
>>
>> kde's kdesu barfs on this second prompt. Any way to disable this second
>> prompt?
>>
>> -- Rex
18 years, 3 months