setroubleshootd dead but pid file exists
by Radha Venkatesh (radvenka)
Hi,
The problem we face is
>>service setroubleshoot status
setroubleshootd dead but pid file exists
We are running into Bug 480432
<https://bugzilla.redhat.com/show_bug.cgi?id=480432> - setroubleshootd
killed - apparently by selinux on our system. The kernel we are running
on is 2.6.18-194.el5PAE and the selinux, setroubleshoot rpms being used
are
libselinux-1.33.4-5.5.el5
selinux-policy-strict-2.4.6-279.el5
platform-selinux-2.0.0.0-1
cm-selinux-2.0.0.0-0
libselinux-python-1.33.4-5.5.el5
libselinux-utils-1.33.4-5.5.el5
selinux-policy-2.4.6-279.el5
setroubleshoot-server-2.0.5-5.el5
setroubleshoot-plugins-2.0.4-2.el5
Is there a workaround for the above issue, if we cannot go to the latest
kernel?
Thanks,
Radha.
13 years, 8 months
pipefs AVC
by Mr Dash Four
I am currently writing a policy file for an application which listens to
a particular port and also communicates with mysqld. During its start-up
(from a script executed in init.d) I am getting the following AVCs:
=================================
type=AVC msg=audit(1283028441.852:19): avc: denied { read } for
pid=1868 comm="voip_sandbox" path="pipe:[11951]" dev=pipefs ino=11951
scontext=unconfined_u:system_r:voip_sandbox_t:s0
tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=fifo_file
type=AVC msg=audit(1283028441.851:18): avc: denied { write } for
pid=1866 comm="voip_sandbox" path="pipe:[11951]" dev=pipefs ino=11951
scontext=unconfined_u:system_r:voip_sandbox_t:s0
tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=fifo_file
type=SYSCALL msg=audit(1283028441.852:19): arch=40000003 syscall=3
per=400000 success=no exit=-13 a0=6 a1=9d58864 a2=94 a3=0 items=0
ppid=1866 pid=1868 auid=0 uid=496 gid=496 euid=496 suid=496 fsuid=496
egid=496 sgid=496 fsgid=496 tty=(none) ses=1 comm="voip_sandbox"
exe="/usr/local/bin/voip_sandbox"
subj=unconfined_u:system_r:voip_sandbox_t:s0 key=(null)
type=SYSCALL msg=audit(1283028441.851:18): arch=40000003 syscall=4
per=400000 success=no exit=-13 a0=7 a1=bf894480 a2=94 a3=bf894480
items=0 ppid=1 pid=1866 auid=0 uid=496 gid=496 euid=496 suid=496
fsuid=496 egid=496 sgid=496 fsgid=496 tty=(none) ses=1
comm="voip_sandbox" exe="/usr/local/bin/voip_sandbox"
subj=unconfined_u:system_r:voip_sandbox_t:s0 key=(null)
type=AVC msg=audit(1283028441.863:20): avc: denied { write } for
pid=1866 comm="voip_sandbox" path="pipe:[11951]" dev=pipefs ino=11951
scontext=unconfined_u:system_r:voip_sandbox_t:s0
tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=fifo_file
type=SYSCALL msg=audit(1283028441.863:20): arch=40000003 syscall=4
per=400000 success=no exit=-13 a0=7 a1=bf8945c0 a2=94 a3=bf8945c0
items=0 ppid=1 pid=1866 auid=0 uid=496 gid=496 euid=496 suid=496
fsuid=496 egid=496 sgid=496 fsgid=496 tty=(none) ses=1
comm="voip_sandbox" exe="/usr/local/bin/voip_sandbox"
subj=unconfined_u:system_r:voip_sandbox_t:s0 key=(null)
=================================
Both pids 1868 and 1866 are related and spawned by the main application.
I take it there is a pipe which needs to be created and accessible to
both processes. How do I find out what pipe it is (name, location) and
how do I prevent this AVCs from happening? Many thanks!
13 years, 8 months
Issue with Gnome setting?
by Dan Thurman
Yes, I know F9 is obsolete but I still use it!
BTW: for some reason I am not getting back selinux emails that I posted
which is why I sent it twice - was the a burp in the mailing
system?
Just need to figure out what this means and a fix for it please?
=================================================
Summary:
SELinux is preventing the gnome-settings- from using potentially mislabeled
files (socket).
Detailed Description:
SELinux has denied gnome-settings- access to potentially mislabeled file(s)
(socket). This means that SELinux will not allow gnome-settings- to use
these
files. It is common for users to edit files in their home directory or tmp
directories and then move (mv) them to system directories. The problem
is that
the files end up with the wrong file context which confined applications
are not
allowed to access.
Allowing Access:
If you want gnome-settings- to access this files, you need to relabel
them using
restorecon -v 'socket'. You might want to relabel the entire directory using
restorecon -R -v '<Unknown>'.
Additional Information:
Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023
Target Context system_u:object_r:tmp_t:s0
Target Objects socket [ sock_file ]
Source gnome-settings-
Source Path /usr/libexec/gnome-settings-daemon
Port <Unknown>
Host gold.cdkkt.com
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.3.1-135.fc9
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name home_tmp_bad_labels
Host Name gold.cdkkt.com
Platform Linux gold.cdkkt.com
2.6.27.25-78.2.56.fc9.i686 #1
SMP Thu Jun 18 12:47:50 EDT 2009 i686 i686
Alert Count 378
First Seen Fri 27 Aug 2010 11:09:22 AM PDT
Last Seen Fri 27 Aug 2010 11:09:26 AM PDT
Local ID bdb33ade-aa41-4dec-a430-ae0ad4594254
Line Numbers
Raw Audit Messages
node=gold.cdkkt.com type=AVC msg=audit(1282932566.767:3581): avc:
denied { read write } for pid=3079 comm="gnome-settings-"
name="socket" dev=sda8 ino=245843
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file
=================================================
13 years, 8 months
NFSD warning?
by Arthur Dent
Hello all,
Working with Dominick to solve my clamd denial problem has caused me to
use ausearch more often than I normally would.
This has revealed a large and constant amount of these messages:
----
time->Thu Aug 26 10:31:37 2010
type=SYSCALL msg=audit(1282815097.754:55608): arch=40000003 syscall=300
success=no exit=-13 a0=9 a1=243c883 a2=bf8d6de0 a3=0 items=0 ppid=1
pid=1228 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm="rpc.mountd"
exe="/usr/sbin/rpc.mountd" subj=system_u:system_r:nfsd_t:s0 key=(null)
type=AVC msg=audit(1282815097.754:55608): avc: denied { getattr } for
pid=1228 comm="rpc.mountd" path="/proc/kcore" dev=proc ino=4026531989
scontext=system_u:system_r:nfsd_t:s0
tcontext=system_u:object_r:proc_kcore_t:s0 tclass=file
----
time->Thu Aug 26 10:31:37 2010
type=SYSCALL msg=audit(1282815097.756:55609): arch=40000003 syscall=5
success=no exit=-13 a0=243bca8 a1=8000 a2=0 a3=243bc68 items=0 ppid=1
pid=1228 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm="rpc.mountd"
exe="/usr/sbin/rpc.mountd" subj=system_u:system_r:nfsd_t:s0 key=(null)
type=AVC msg=audit(1282815097.756:55609): avc: denied { read } for
pid=1228 comm="rpc.mountd" name="sda11" dev=devtmpfs ino=5616
scontext=system_u:system_r:nfsd_t:s0
tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file
----
time->Thu Aug 26 10:37:51 2010
type=AVC msg=audit(1282815471.028:55622): avc: denied { 0x400000 } for
pid=1223 comm="nfsd" name="" dev=sda11 ino=28365
scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
----
time->Thu Aug 26 10:37:51 2010
type=AVC msg=audit(1282815471.028:55623): avc: denied { 0x400000 } for
pid=1221 comm="nfsd" name="" dev=sda11 ino=28365
scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
----
time->Thu Aug 26 10:37:51 2010
type=AVC msg=audit(1282815471.063:55624): avc: denied { 0x400000 } for
pid=1221 comm="nfsd" name="" dev=sda11 ino=28365
scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
----
time->Thu Aug 26 10:37:51 2010
type=AVC msg=audit(1282815471.076:55625): avc: denied { 0x400000 } for
pid=1223 comm="nfsd" name="" dev=sda11 ino=28365
scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
----
time->Thu Aug 26 10:37:51 2010
type=AVC msg=audit(1282815471.101:55626): avc: denied { 0x400000 } for
pid=1223 comm="nfsd" name="" dev=sda11 ino=28365
scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
----
time->Thu Aug 26 10:37:51 2010
type=AVC msg=audit(1282815471.122:55627): avc: denied { 0x400000 } for
pid=1223 comm="nfsd" name="" dev=sda11 ino=28365
scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
----
time->Thu Aug 26 10:37:51 2010
type=AVC msg=audit(1282815471.136:55628): avc: denied { 0x400000 } for
pid=1223 comm="nfsd" name="" dev=sda11 ino=28365
scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
----
time->Thu Aug 26 10:37:51 2010
type=AVC msg=audit(1282815471.154:55629): avc: denied { 0x400000 } for
pid=1223 comm="nfsd" name="" dev=sda11 ino=28365
scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
----
time->Thu Aug 26 10:43:30 2010
type=AVC msg=audit(1282815810.307:55648): avc: denied { 0x400000 } for
pid=1223 comm="nfsd" name="" dev=sda11 ino=28365
scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
----
time->Thu Aug 26 10:43:30 2010
type=AVC msg=audit(1282815810.321:55649): avc: denied { 0x400000 } for
pid=1223 comm="nfsd" name="" dev=sda11 ino=28365
scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
----
time->Thu Aug 26 10:43:30 2010
type=AVC msg=audit(1282815810.335:55650): avc: denied { 0x400000 } for
pid=1223 comm="nfsd" name="" dev=sda11 ino=28365
scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
----
time->Thu Aug 26 10:43:30 2010
type=AVC msg=audit(1282815810.354:55651): avc: denied { 0x400000 } for
pid=1223 comm="nfsd" name="" dev=sda11 ino=28365
scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
----
time->Thu Aug 26 10:45:04 2010
type=SYSCALL msg=audit(1282815904.588:55656): arch=40000003 syscall=11
success=yes exit=0 a0=15559d0 a1=bf9c9f7c a2=303840 a3=41904 items=0
ppid=3571 pid=3572 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail"
exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null)
type=AVC msg=audit(1282815904.588:55656): avc: denied { noatsecure }
for pid=3572 comm="procmail" scontext=system_u:system_r:sendmail_t:s0
tcontext=system_u:system_r:procmail_t:s0 tclass=process
type=AVC msg=audit(1282815904.588:55656): avc: denied { siginh } for
pid=3572 comm="procmail" scontext=system_u:system_r:sendmail_t:s0
tcontext=system_u:system_r:procmail_t:s0 tclass=process
type=AVC msg=audit(1282815904.588:55656): avc: denied { rlimitinh }
for pid=3572 comm="procmail" scontext=system_u:system_r:sendmail_t:s0
tcontext=system_u:system_r:procmail_t:s0 tclass=process
/dev/sda11 is a Fat32 partition mounted in /etc/fstab with the line:
/dev/sda11 /mnt/tempstore vfat users,rw,uid=mark 0 2
and shared as an NFS mount on my desktop.
# cat /etc/exports
/home/mark 192.168.2.4(rw,async,no_subtree_check,nohide,no_root_squash)
/mnt/tempstore 192.168.2.4(rw,async,no_subtree_check,nohide,no_root_squash)
/mnt/datastore 192.168.2.4(rw,async,no_subtree_check,nohide,no_root_squash)
/mnt/f11 192.168.2.4(rw,async,no_subtree_check,nohide,no_root_squash)
Are the avcs a problem and how do I stop them? Audit2allow does not
produce anything on these messages....
Thanks
Mark
13 years, 8 months
Clamd - again...
by Arthur Dent
Hello all,
Since upgrading from F11 to F13 I still have 3 outstanding issues. 1 is
my earlier thread about mlogc which is still the subject of some
correspondence on the modsecurity list, another is a mysterious "leaked
file descriptor" AVC which has a permissive type anyway so I will worry
about that later (and may have stopped since the latest selinux policy
release) and that just leaves clamd... sigh...
The relationship between procmail and clamd and selinux always seems to
be a troubled one and I don't know why it should be so, but hey...
Every time I upgrade Fedora I go through this little dance - remove my
old home made clamd policy, run my fetchmail->procmail->clamd( and
spamd)-> dovecot mail-chain and see what AVCs emerge. I create a policy
using audit2allow, rinse, repeat until all AVCs go away.
Well I have done that as usual, all the AVCs have gone away, but still I
get this message in my logs:
X-virus-report: /usr/local/bin/clamdscan error 2
X-virus-checker-version: clamassassin 1.2.4 with clamdscan / ERROR: Can't connect to clamd: Permission denied
But NO AVCs
I have proved that selinux is the culprit. Putting SEL into permissive
mode temporarily allows clamd to work as it should (but still no AVCs).
I am a little reluctant to do the "semodule -DB" to reveal any silent
denials as I get swamped with stuff (but if that's what it takes...)
In the meantime can anyone suggest any other approach?
Here is my current clamd module as created by audit2allow:
=========================8<========================================
# cat selinux/myclamd.te
module myclamd 13.1.3;
require {
type unconfined_t;
type var_run_t;
type clamd_var_run_t;
type initrc_t;
type procmail_t;
class sock_file write;
class unix_stream_socket connectto;
}
#============= procmail_t ==============
allow procmail_t initrc_t:unix_stream_socket connectto;
#!!!! This avc is allowed in the current policy
allow procmail_t unconfined_t:unix_stream_socket connectto;
#!!!! This avc is allowed in the current policy
allow procmail_t var_run_t:sock_file write;
allow procmail_t clamd_var_run_t:sock_file write;
#!!!! This avc is allowed in the current policy
=========================8<========================================
Note - those comments are created by audit2allow.
Thanks in advance...
Mark
13 years, 8 months
Re: This isn't nice
by mark
Stephen John Smoogen wrote:
> On Wed, Aug 18, 2010 at 14:51, <m.roth(a)5-cent.us> wrote:
>> Well, I dunno if this is a bug with fedora or selinux, but my FC13 system
>> crashed earlier today with:
>>
>> Aug 18 13:01:56 argo kernel: SELinux: Invalid class 0
>> Aug 18 13:11:23 argo kernel: BUG: unable to handle kernel NULL pointer
>> dereference at 0000000000000008
>> Aug 18 13:11:23 argo kernel: IP: [<ffffffff811c73b6>]
>> selinux_inode_free_security+0x3f/0x77
>> Aug 18 13:11:23 argo kernel: PGD 139db9067 PUD 12dde6067 PMD 0
>> Aug 18 13:11:23 argo kernel: Oops: 0002 [#1] SMP
>> Aug 18 13:11:23 argo kernel: last sysfs file:
>> /sys/devices/pci0000:00/0000:00:1c.0/0000:0b:00.0/local_cpus
>> Aug 18 13:11:23 argo kernel: CPU 2
>> Aug 18 13:11:23 argo kernel: Pid: 50, comm: kswapd0 Tainted: P
>
> # P: A module with a Proprietary license has been loaded, i.e. a
> module that is not licensed under the GNU General Public License (GPL)
> or a compatible license. This may indicate that source code for this
> module is not available to the Linux kernel developers or to Novell's
> developers.
>
Um, not so far as I know. I used preupgrade to bring an FC10 system to FC13.
Other than the drives being encrypted (LUKS works), to the best of my knowledge
- and I was the one who did the upgrade, there is *nothing* non-standard.
mark
> Whats loaded to cause that?
>
>> mark, very unhappy with FC13....
--
O'Leary, O'Reilly, O'Hare and O'Hara, there's no one as Irish as Barack
O'Bama..." - "There's no one as Irish as Barack O'Bama, the Corrigan Bros.
13 years, 8 months
using port (sub)ranges
by Mr Dash Four
I am trying to build a custom policy for one of my applications, which
needs to:
1. Listen on a predefined range of tcp/udp ports (49200-49232); and
2. Connect to 25, 465, 110, 143, 993 & 995 tcp and 443, 1194 udp ports
All is done on the local (lo) interface, NOT ethX (this should be
prevented, if attempted!). The above port ranges cannot be changed!
There are a couple of difficulties I am facing, however:
1. The first range of ports already form part of the 'virt' port ranges
(49152-49216) in corenetwork.te.in. How do I define/use my own set of
ranges (even if it clashes with another range type defined elsewhere) in
order to allow 'corenet_tcp_bind' and 'corenet_udp_bind' macros to do
their job and use them in my custom.te? Is there another way of doing
name_bind?
2. The second port ranges form part of the 'pop', 'smtp' and 'openvpn'
(as defined in corenetwork.te.in), but I do not wish to use the whole
ranges when allowing a connection to be made. I also want to restrict
these connections to be on the local interface only. Is there a way I
could do that in my custom.te?
Thanks in advance!
13 years, 8 months
This isn't nice
by mark
Well, I dunno if this is a bug with fedora or selinux, but my FC13 system
crashed earlier today with:
Aug 18 13:01:56 argo kernel: SELinux: Invalid class 0
Aug 18 13:11:23 argo kernel: BUG: unable to handle kernel NULL pointer
dereference at 0000000000000008
Aug 18 13:11:23 argo kernel: IP: [<ffffffff811c73b6>]
selinux_inode_free_security+0x3f/0x77
Aug 18 13:11:23 argo kernel: PGD 139db9067 PUD 12dde6067 PMD 0
Aug 18 13:11:23 argo kernel: Oops: 0002 [#1] SMP
Aug 18 13:11:23 argo kernel: last sysfs file:
/sys/devices/pci0000:00/0000:00:1c.0/0000:0b:00.0/local_cpus
Aug 18 13:11:23 argo kernel: CPU 2
Aug 18 13:11:23 argo kernel: Pid: 50, comm: kswapd0 Tainted: P
2.6.33.6-147.fc13.x86_64 #1 0GU083/Precision WorkStation 490
Aug 18 13:11:23 argo kernel: RIP: 0010:[<ffffffff811c73b6>]
[<ffffffff811c73b6>] selinux_inode_free_security+0x3f/0x77
Aug 18 13:11:23 argo kernel: RSP: 0018:ffff88013a0e7bf0 EFLAGS: 00010213
Aug 18 13:11:23 argo kernel: RAX: ffff880126f15008 RBX: ffff880126f15000
RCX: 0000000000000000
Aug 18 13:11:23 argo kernel: RDX: 0000000000000000 RSI: ffff880005890500
RDI: ffff880137156860
Aug 18 13:11:23 argo kernel: RBP: ffff88013a0e7c10 R08: ffff880011d2e980
R09: 0000000000000005
Aug 18 13:11:23 argo kernel: R10: ffff880011d2e860 R11: ffff880011d2e650
R12: ffff880011d2e970
Aug 18 13:11:23 argo kernel: R13: ffff880137156800 R14: ffff88013a0e7cb0
R15: 0000000000000080
Aug 18 13:11:23 argo kernel: FS: 0000000000000000(0000)
GS:ffff880005880000(0000) knlGS:0000000000000000
Aug 18 13:11:23 argo kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
Aug 18 13:11:23 argo kernel: CR2: 0000000000000008 CR3: 000000012ddfd000
CR4: 00000000000006e0
Aug 18 13:11:23 argo kernel: DR0: 0000000000000000 DR1: 0000000000000000
DR2: 0000000000000000
Aug 18 13:11:23 argo kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0
DR7: 0000000000000400
Aug 18 13:11:23 argo kernel: Process kswapd0 (pid: 50, threadinfo
ffff88013a0e6000, task ffff88013b0f2ea0)
Aug 18 13:11:23 argo kernel: Stack:
Aug 18 13:11:23 argo kernel: ffff88013a0e7c10 ffff880011d2e970
ffff880011d2e980 000000000000007d
Aug 18 13:11:23 argo kernel: <0> ffff88013a0e7c30 ffffffff811be70b
0000000000000000 ffff880011d2e970
Aug 18 13:11:23 argo kernel: <0> ffff88013a0e7c50 ffffffff811130d4
ffff880011d2eb80 ffff880011d2e970
Aug 18 13:11:23 argo kernel: Call Trace:
Aug 18 13:11:23 argo kernel: [<ffffffff811be70b>]
security_inode_free+0x21/0x25
Aug 18 13:11:23 argo kernel: [<ffffffff811130d4>] __destroy_inode+0x21/0x78
Aug 18 13:11:23 argo kernel: [<ffffffff8111313c>] destroy_inode+0x11/0x40
Aug 18 13:11:23 argo kernel: [<ffffffff811135d4>] dispose_list+0xbe/0xed
Aug 18 13:11:23 argo kernel: [<ffffffff811137d1>]
shrink_icache_memory+0x1ce/0x1fe
Aug 18 13:11:23 argo kernel: [<ffffffff810cb017>] shrink_slab+0xd3/0x157
Aug 18 13:11:23 argo kernel: [<ffffffff810cd0db>] balance_pgdat+0x3af/0x5e3
Aug 18 13:11:23 argo kernel: [<ffffffff810ca7ae>] ?
isolate_pages_global+0x0/0x1f2
Aug 18 13:11:23 argo kernel: [<ffffffff810cd550>] kswapd+0x241/0x26d
Aug 18 13:11:23 argo kernel: [<ffffffff810641bf>] ?
autoremove_wake_function+0x0/0x34
Aug 18 13:11:23 argo kernel: [<ffffffff810cd30f>] ? kswapd+0x0/0x26d
Aug 18 13:11:23 argo kernel: [<ffffffff81063d6f>] kthread+0x7a/0x82
Aug 18 13:11:23 argo kernel: [<ffffffff8100a924>]
kernel_thread_helper+0x4/0x10
Aug 18 13:11:23 argo kernel: [<ffffffff81063cf5>] ? kthread+0x0/0x82
Aug 18 13:11:23 argo kernel: [<ffffffff8100a920>] ?
kernel_thread_helper+0x0/0x10
Aug 18 13:11:23 argo kernel: Code: 01 00 00 48 8b 9f 28 02 00 00 4c 8b a8
c0 00 00 00 49 8d 7d 60 e8 ec 2c 26 00 48 8b 53 08 48 8d 43 08 48 39 c2 74
13 48 8b 4b 10 <48> 89 4a 08 48 89 11 48 89 43 08 48 89 43 10 66 41 ff 45
60 49
Aug 18 13:11:23 argo kernel: RIP [<ffffffff811c73b6>]
selinux_inode_free_security+0x3f/0x77
Aug 18 13:11:23 argo kernel: RSP <ffff88013a0e7bf0>
Aug 18 13:11:23 argo kernel: CR2: 0000000000000008
Aug 18 13:11:23 argo kernel: ---[ end trace 4543cd894c4be801 ]---
mark, very unhappy with FC13....
13 years, 8 months
Create denial on nshadow when logging in with an expired password
by Patrice GILLET (Ingenico Partner)
Hi everyone,
I'm running selinux-policy-strict 2.4.6-279.el5_5.1 (Redhat), and I get
a denial when a user logs on (via SSH) with an expired password. The
procedure for getting the new password goes fine, but the update of
shadow fails and the login is refused. The audit messages are the
following:
type=USER_AUTH msg=audit(1282326913.918:472): user pid=14136 uid=0
auid=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='PAM:
authentication acct="testupgrader" : exe="/usr/sbin/sshd"
(hostname=xx.xx.xx.xx, addr=xx.xx.xx.xx, terminal=ssh res=failed)'
type=USER_LOGIN msg=audit(1282326913.918:473): user pid=14136 uid=0
auid=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
msg='acct="testupgrader": exe="/usr/sbin/sshd" (hostname=?,
addr=xx.xx.xx.xx, terminal=sshd res=failed)'
type=USER_AUTH msg=audit(1282326917.387:474): user pid=14136 uid=0
auid=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='PAM:
authentication acct="testupgrader" : exe="/usr/sbin/sshd"
(hostname=xx.xx.xx.xx, addr=xx.xx.xx.xx, terminal=ssh res=success)'
type=USER_ACCT msg=audit(1282326917.388:475): user pid=14136 uid=0
auid=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='PAM:
accounting acct="testupgrader" : exe="/usr/sbin/sshd"
(hostname=xx.xx.xx.xx, addr=xx.xx.xx.xx, terminal=ssh res=failed)'
type=CRED_ACQ msg=audit(1282326917.393:476): user pid=14136 uid=0
auid=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='PAM:
setcred acct="testupgrader" : exe="/usr/sbin/sshd"
(hostname=xx.xx.xx.xx, addr=xx.xx.xx.xx, terminal=ssh res=success)'
type=LOGIN msg=audit(1282326917.393:477): login pid=14136 uid=0 old
auid=4294967295 new auid=508 old ses=4294967295 new ses=26
type=USER_START msg=audit(1282326917.393:478): user pid=14136 uid=0
auid=508 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='PAM: session
open acct="testupgrader" : exe="/usr/sbin/sshd" (hostname=xx.xx.xx.xx,
addr=xx.xx.xx.xx, terminal=ssh res=success)'
type=CRED_REFR msg=audit(1282326917.394:479): user pid=14138 uid=0
auid=508 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='PAM: setcred
acct="testupgrader" : exe="/usr/sbin/sshd" (hostname=xx.xx.xx.xx,
addr=xx.xx.xx.xx, terminal=ssh res=success)'
type=USER_LOGIN msg=audit(1282326917.397:480): user pid=14136 uid=0
auid=508 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='uid=508:
exe="/usr/sbin/sshd" (hostname=xx.xx.xx.xx, addr=xx.xx.xx.xx,
terminal=/dev/pts/7 res=success)'
type=AVC msg=audit(1282326929.157:481): avc: denied { create } for
pid=14139 comm="passwd" name="nshadow"
scontext=e2ee_upgrader_u:e2ee_upgrader_r:e2ee_upgrader_t:s0
tcontext=system_u:object_r:shadow_t:s0 tclass=file
type=SYSCALL msg=audit(1282326929.157:481): arch=c000003e syscall=2
success=no exit=-13 a0=2ad97d295a33 a1=241 a2=1b6 a3=241 items=0
ppid=14138 pid=14139 auid=508 uid=508 gid=508 euid=0 suid=0 fsuid=0
egid=508 sgid=508 fsgid=508 tty=pts7 ses=26 comm="passwd"
exe="/usr/bin/passwd"
subj=e2ee_upgrader_u:e2ee_upgrader_r:e2ee_upgrader_t:s0 key=(null)
type=USER_CHAUTHTOK msg=audit(1282326931.330:482): user pid=14139
uid=508 auid=508 subj=e2ee_upgrader_u:e2ee_upgrader_r:e2ee_upgrader_t:s0
msg='PAM: chauthtok acct="testupgrader" : exe="/usr/bin/passwd"
(hostname=?, addr=?, terminal=pts/7 res=failed)'
type=USER_CHAUTHTOK msg=audit(1282326931.330:483): user pid=14139
uid=508 auid=508 subj=e2ee_upgrader_u:e2ee_upgrader_r:e2ee_upgrader_t:s0
msg='op=change password id=508 exe="/usr/bin/passwd" (hostname=?,
addr=?, terminal=pts/7 res=failed)'
type=CRED_DISP msg=audit(1282326931.332:484): user pid=14136 uid=0
auid=508 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='PAM: setcred
acct="testupgrader" : exe="/usr/sbin/sshd" (hostname=xx.xx.xx.xx,
addr=xx.xx.xx.xx, terminal=ssh res=success)'
type=USER_END msg=audit(1282326931.332:485): user pid=14136 uid=0
auid=508 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='PAM: session
close acct="testupgrader" : exe="/usr/sbin/sshd" (hostname=xx.xx.xx.xx,
addr=xx.xx.xx.xx, terminal=ssh res=success)'
Audit2allow suggests to add auth_manage_shadow(e2ee_upgrader_t) to the
local policy, but that doesn't change anything. Neither does adding
allow e2ee_upgrader_t shadow_t:file { create }.
What is really strange is that the very same user (after its password
has been changed by root) can run passwd and set its password without
any problem.
Any idea?
Thanks in advance for any suggestion,
Patrice.
13 years, 8 months
