11:01 a.m.
I have a Fedora 16 box where something seems to have gone sideways with
SELinux. I am unable to log into the box with SELinux enabled. I see
messages in /var/log/messages that look like this:
Apr 11 02:40:06 rail setroubleshoot: SELinux is preventing
/usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete
SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:40:06 rail setroubleshoot: SELinux is preventing
/usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete
SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:40:07 rail setroubleshoot: SELinux is preventing
/usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete
SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:40:10 rail setroubleshoot: SELinux is preventing
/usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete
SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:40:26 rail setroubleshoot: SELinux is preventing
/usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete
SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:40:58 rail setroubleshoot: SELinux is preventing
/usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete
SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:02 rail setroubleshoot: SELinux is preventing
/usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete
SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:02 rail setroubleshoot: SELinux is preventing
/usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete
SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:02 rail setroubleshoot: SELinux is preventing
/usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete
SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:06 rail setroubleshoot: SELinux is preventing
/usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete
SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:14 rail setroubleshoot: SELinux is preventing
/usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete
SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:30 rail setroubleshoot: SELinux is preventing
/usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete
SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:43:02 rail setroubleshoot: SELinux is preventing
/usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete
SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
I tried doing a full relabel; but that had no noticeable effect. If I
boot to single user mode and disable SELinux (via /etc/selinux/config),
I'm able to log in and things appear to be functional. Well, with the
caveat that the suggestion in the message to run sealert yields this:
# sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Opps, sealert hit an error!
Traceback (most recent call last):
File "/usr/bin/sealert", line 668, in <module>
proxy_obj = bus.get_object(dbus_system_bus_name, dbus_system_object_path)
File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 244, in
get_object
follow_name_owner_changes=follow_name_owner_changes)
File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 241, in
__init__
self._named_service = conn.activate_name_owner(bus_name)
File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 183, in
activate_name_owner
self.start_service_by_name(bus_name)
File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 281, in
start_service_by_name
'su', (bus_name, flags)))
File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 630,
in call_blocking
message, timeout)
DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited
with unknown return code 3
Any idea what happened here and how I might actually fix it?
--
Braden McDaniel <braden(a)endoframe.com>
1:45 p.m.
On 04/11/2012 12:01 PM, Braden McDaniel wrote:
I have a Fedora 16 box where something seems to have gone sideways
with
SELinux. I am unable to log into the box with SELinux enabled. I see
messages in /var/log/messages that look like this:
Apr 11 02:40:06 rail setroubleshoot: SELinux is preventing
/usr/libexec/accounts-daemon from name_connect access on the tcp_socket .
For complete SELinux messages. run sealert -l
aeded892-dec1-4e6d-87ce-7c10a4e42e2b Apr 11 02:40:06 rail setroubleshoot:
SELinux is preventing /usr/libexec/accounts-daemon from name_connect access
on the tcp_socket . For complete SELinux messages. run sealert -l
aeded892-dec1-4e6d-87ce-7c10a4e42e2b Apr 11 02:40:07 rail setroubleshoot:
SELinux is preventing /usr/libexec/accounts-daemon from name_connect access
on the tcp_socket . For complete SELinux messages. run sealert -l
aeded892-dec1-4e6d-87ce-7c10a4e42e2b Apr 11 02:40:10 rail setroubleshoot:
SELinux is preventing /usr/libexec/accounts-daemon from name_connect access
on the tcp_socket . For complete SELinux messages. run sealert -l
aeded892-dec1-4e6d-87ce-7c10a4e42e2b Apr 11 02:40:26 rail setroubleshoot:
SELinux is preventing /usr/libexec/accounts-daemon from name_connect access
on the tcp_socket . For complete SELinux messages. run sealert -l
aeded892-dec1-4e6d-87ce-7c10a4e42e2b Apr 11 02:40:58 rail setroubleshoot:
SELinux is preventing /usr/libexec/accounts-daemon from name_connect access
on the tcp_socket . For complete SELinux messages. run sealert -l
aeded892-dec1-4e6d-87ce-7c10a4e42e2b Apr 11 02:42:02 rail setroubleshoot:
SELinux is preventing /usr/libexec/accounts-daemon from name_connect access
on the tcp_socket . For complete SELinux messages. run sealert -l
aeded892-dec1-4e6d-87ce-7c10a4e42e2b Apr 11 02:42:02 rail setroubleshoot:
SELinux is preventing /usr/libexec/accounts-daemon from name_connect access
on the tcp_socket . For complete SELinux messages. run sealert -l
aeded892-dec1-4e6d-87ce-7c10a4e42e2b Apr 11 02:42:02 rail setroubleshoot:
SELinux is preventing /usr/libexec/accounts-daemon from name_connect access
on the tcp_socket . For complete SELinux messages. run sealert -l
aeded892-dec1-4e6d-87ce-7c10a4e42e2b Apr 11 02:42:06 rail setroubleshoot:
SELinux is preventing /usr/libexec/accounts-daemon from name_connect access
on the tcp_socket . For complete SELinux messages. run sealert -l
aeded892-dec1-4e6d-87ce-7c10a4e42e2b Apr 11 02:42:14 rail setroubleshoot:
SELinux is preventing /usr/libexec/accounts-daemon from name_connect access
on the tcp_socket . For complete SELinux messages. run sealert -l
aeded892-dec1-4e6d-87ce-7c10a4e42e2b Apr 11 02:42:30 rail setroubleshoot:
SELinux is preventing /usr/libexec/accounts-daemon from name_connect access
on the tcp_socket . For complete SELinux messages. run sealert -l
aeded892-dec1-4e6d-87ce-7c10a4e42e2b Apr 11 02:43:02 rail setroubleshoot:
SELinux is preventing /usr/libexec/accounts-daemon from name_connect access
on the tcp_socket . For complete SELinux messages. run sealert -l
aeded892-dec1-4e6d-87ce-7c10a4e42e2b
I tried doing a full relabel; but that had no noticeable effect. If I boot
to single user mode and disable SELinux (via /etc/selinux/config), I'm able
to log in and things appear to be functional. Well, with the caveat that
the suggestion in the message to run sealert yields this:
# sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b Opps, sealert hit an
error!
Traceback (most recent call last): File "/usr/bin/sealert", line 668, in
<module> proxy_obj = bus.get_object(dbus_system_bus_name,
dbus_system_object_path) File
"/usr/lib/python2.7/site-packages/dbus/bus.py", line 244, in get_object
follow_name_owner_changes=follow_name_owner_changes) File
"/usr/lib/python2.7/site-packages/dbus/proxies.py", line 241, in __init__
self._named_service = conn.activate_name_owner(bus_name) File
"/usr/lib/python2.7/site-packages/dbus/bus.py", line 183, in
activate_name_owner self.start_service_by_name(bus_name) File
"/usr/lib/python2.7/site-packages/dbus/bus.py", line 281, in
start_service_by_name 'su', (bus_name, flags))) File
"/usr/lib/python2.7/site-packages/dbus/connection.py", line 630, in
call_blocking message, timeout) DBusException:
org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with
unknown return code 3
Any idea what happened here and how I might actually fix it?
What does
ausearch -m avc -ts recent
show?
1:51 p.m.
On Wed, 2012-04-11 at 14:45 -0400, Daniel J Walsh wrote:
On 04/11/2012 12:01 PM, Braden McDaniel wrote:
> I have a Fedora 16 box where something seems to have gone sideways with
> SELinux. I am unable to log into the box with SELinux enabled. I see
> messages in /var/log/messages that look like this:
>
> Apr 11 02:40:06 rail setroubleshoot: SELinux is preventing
> /usr/libexec/accounts-daemon from name_connect access on the tcp_socket .
> For complete SELinux messages. run sealert -l
[snip]
> Any idea what happened here and how I might actually fix it?
>
What does
ausearch -m avc -ts recent
show?
# ausearch -m avc -ts recent
<no matches>
--
Braden McDaniel <braden(a)endoframe.com>
2:37 p.m.
On Wed, 2012-04-11 at 15:25 -0400, Daniel J Walsh wrote:
Are you booted with SELinux in permissive mode of disabled?
I'm booted with it disabled:
# cat /etc/selinux/config | grep disabled
# disabled - No SELinux policy is loaded.
SELINUX=disabled
ausearch -m avc
That's long; I'll attach it.
--
Braden McDaniel <braden(a)endoframe.com>
4:27 p.m.
On Wed, Apr 11, 2012 at 03:37:45PM -0400, Braden McDaniel wrote:
On Wed, 2012-04-11 at 15:25 -0400, Daniel J Walsh wrote:
> Are you booted with SELinux in permissive mode of disabled?
I'm booted with it disabled:
# cat /etc/selinux/config | grep disabled
# disabled - No SELinux policy is loaded.
SELINUX=disabled
> ausearch -m avc
That's long; I'll attach it.
You might want to try this as root first, after saving your work:
touch /.autorelabel ; reboot
Running SELinux disabled is unnecessary. Running in permissive mode
is much better, since it allows you to switch back and forth without
labeling problems.
When you run in disabled mode, SELinux labels aren't written to the
disk when files are created, so when you try to turn SELinux on later,
it results in lots of denial errors. Permissive mode does pretty much
the same thing as enforcing mode, but any denials are ignored, so
SELinux won't prevent access.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
9:27 p.m.
On Wed, 2012-04-11 at 17:27 -0400, Paul W. Frields wrote:
On Wed, Apr 11, 2012 at 03:37:45PM -0400, Braden McDaniel wrote:
> On Wed, 2012-04-11 at 15:25 -0400, Daniel J Walsh wrote:
> > Are you booted with SELinux in permissive mode of disabled?
>
> I'm booted with it disabled:
>
> # cat /etc/selinux/config | grep disabled
> # disabled - No SELinux policy is loaded.
> SELINUX=disabled
>
> > ausearch -m avc
>
> That's long; I'll attach it.
You might want to try this as root first, after saving your work:
touch /.autorelabel ; reboot
I did that previously; but it didn't seem to help. (Perhaps because I
still had SELinux disabled when I did it?)
Running SELinux disabled is unnecessary. Running in permissive mode
is much better, since it allows you to switch back and forth without
labeling problems.
When you run in disabled mode, SELinux labels aren't written to the
disk when files are created, so when you try to turn SELinux on later,
it results in lots of denial errors. Permissive mode does pretty much
the same thing as enforcing mode, but any denials are ignored, so
SELinux won't prevent access.
That's likely how I got myself into this. I had disabled it while
attempting to troubleshoot something else. I probably installed and/or
updated some packages before I remembered to turn it back on.
So I changed to "permissive" and did the autorelabel thing again. This
time I was able to zero in on some messages that were likely pertinent;
and the SELinux troubleshooter suggested:
setsebool -P authlogin_nsswitch_use_ldap 1
I'll continue to run "permissive" for a little while longer and see if
that fixes it.
--
Braden McDaniel <braden(a)endoframe.com>
3:10 p.m.
On 04/11/2012 10:27 PM, Braden McDaniel wrote:
On Wed, 2012-04-11 at 17:27 -0400, Paul W. Frields wrote:
> On Wed, Apr 11, 2012 at 03:37:45PM -0400, Braden McDaniel wrote:
>> On Wed, 2012-04-11 at 15:25 -0400, Daniel J Walsh wrote:
>>> Are you booted with SELinux in permissive mode of disabled?
>>
>> I'm booted with it disabled:
>>
>> # cat /etc/selinux/config | grep disabled # disabled - No SELinux
>> policy is loaded. SELINUX=disabled
>>
>>> ausearch -m avc
>>
>> That's long; I'll attach it.
>
> You might want to try this as root first, after saving your work:
>
> touch /.autorelabel ; reboot
I did that previously; but it didn't seem to help. (Perhaps because I still
had SELinux disabled when I did it?)
> Running SELinux disabled is unnecessary. Running in permissive mode is
> much better, since it allows you to switch back and forth without
> labeling problems.
>
> When you run in disabled mode, SELinux labels aren't written to the disk
> when files are created, so when you try to turn SELinux on later, it
> results in lots of denial errors. Permissive mode does pretty much the
> same thing as enforcing mode, but any denials are ignored, so SELinux
> won't prevent access.
That's likely how I got myself into this. I had disabled it while
attempting to troubleshoot something else. I probably installed and/or
updated some packages before I remembered to turn it back on.
So I changed to "permissive" and did the autorelabel thing again. This
time I was able to zero in on some messages that were likely pertinent; and
the SELinux troubleshooter suggested:
setsebool -P authlogin_nsswitch_use_ldap 1
I'll continue to run "permissive" for a little while longer and see if
that
fixes it.
What AVC indicated that you needed this? Are you using pam_ldap? ldap for
user authorization?
We just added the ability for samba to use ldap, out of the box.
7:47 p.m.
On Thu, 2012-04-12 at 16:10 -0400, Daniel J Walsh wrote:
On 04/11/2012 10:27 PM, Braden McDaniel wrote:
> On Wed, 2012-04-11 at 17:27 -0400, Paul W. Frields wrote:
>> On Wed, Apr 11, 2012 at 03:37:45PM -0400, Braden McDaniel wrote:
>>> On Wed, 2012-04-11 at 15:25 -0400, Daniel J Walsh wrote:
>>>> Are you booted with SELinux in permissive mode of disabled?
>>>
>>> I'm booted with it disabled:
>>>
>>> # cat /etc/selinux/config | grep disabled # disabled - No SELinux
>>> policy is loaded. SELINUX=disabled
>>>
>>>> ausearch -m avc
>>>
>>> That's long; I'll attach it.
>>
>> You might want to try this as root first, after saving your work:
>>
>> touch /.autorelabel ; reboot
>
> I did that previously; but it didn't seem to help. (Perhaps because I still
> had SELinux disabled when I did it?)
>
>> Running SELinux disabled is unnecessary. Running in permissive mode is
>> much better, since it allows you to switch back and forth without
>> labeling problems.
>>
>> When you run in disabled mode, SELinux labels aren't written to the disk
>> when files are created, so when you try to turn SELinux on later, it
>> results in lots of denial errors. Permissive mode does pretty much the
>> same thing as enforcing mode, but any denials are ignored, so SELinux
>> won't prevent access.
>
> That's likely how I got myself into this. I had disabled it while
> attempting to troubleshoot something else. I probably installed and/or
> updated some packages before I remembered to turn it back on.
>
> So I changed to "permissive" and did the autorelabel thing again. This
> time I was able to zero in on some messages that were likely pertinent; and
> the SELinux troubleshooter suggested:
>
> setsebool -P authlogin_nsswitch_use_ldap 1
>
> I'll continue to run "permissive" for a little while longer and see if
that
> fixes it.
>
What AVC indicated that you needed this?
Unfortunately, I deleted it. However, I think it was one corresponding
to a /var/log/messages entry like this one:
Apr 10 23:58:31 rail setroubleshoot: SELinux is preventing
/usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete
SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Are you using pam_ldap? ldap for
user authorization?
We just added the ability for samba to use ldap, out of the box.
I am using Kerberos for authentication; but I'm using LDAP for user
information.
(Though I get the impression that login is currently falling back to
local authentication; because I don't have a Kerberos ticket after I log
in.)
--
Braden McDaniel <braden(a)endoframe.com>
9:55 p.m.
On 04/12/2012 08:47 PM, Braden McDaniel wrote:
On Thu, 2012-04-12 at 16:10 -0400, Daniel J Walsh wrote:
> On 04/11/2012 10:27 PM, Braden McDaniel wrote:
>> On Wed, 2012-04-11 at 17:27 -0400, Paul W. Frields wrote:
>>> On Wed, Apr 11, 2012 at 03:37:45PM -0400, Braden McDaniel wrote:
>>>> On Wed, 2012-04-11 at 15:25 -0400, Daniel J Walsh wrote:
>>>>> Are you booted with SELinux in permissive mode of disabled?
>>>>
>>>> I'm booted with it disabled:
>>>>
>>>> # cat /etc/selinux/config | grep disabled # disabled - No
>>>> SELinux policy is loaded. SELINUX=disabled
>>>>
>>>>> ausearch -m avc
>>>>
>>>> That's long; I'll attach it.
>>>
>>> You might want to try this as root first, after saving your work:
>>>
>>> touch /.autorelabel ; reboot
>>
>> I did that previously; but it didn't seem to help. (Perhaps because I
>> still had SELinux disabled when I did it?)
>>
>>> Running SELinux disabled is unnecessary. Running in permissive mode
>>> is much better, since it allows you to switch back and forth without
>>> labeling problems.
>>>
>>> When you run in disabled mode, SELinux labels aren't written to the
>>> disk when files are created, so when you try to turn SELinux on
>>> later, it results in lots of denial errors. Permissive mode does
>>> pretty much the same thing as enforcing mode, but any denials are
>>> ignored, so SELinux won't prevent access.
>>
>> That's likely how I got myself into this. I had disabled it while
>> attempting to troubleshoot something else. I probably installed and/or
>> updated some packages before I remembered to turn it back on.
>>
>> So I changed to "permissive" and did the autorelabel thing again.
This
>> time I was able to zero in on some messages that were likely
>> pertinent; and the SELinux troubleshooter suggested:
>>
>> setsebool -P authlogin_nsswitch_use_ldap 1
>>
>> I'll continue to run "permissive" for a little while longer and see
if
>> that fixes it.
>>
>
>
> What AVC indicated that you needed this?
Unfortunately, I deleted it. However, I think it was one corresponding to
a /var/log/messages entry like this one:
Apr 10 23:58:31 rail setroubleshoot: SELinux is preventing
/usr/libexec/accounts-daemon from name_connect access on the tcp_socket .
For complete SELinux messages. run sealert -l
aeded892-dec1-4e6d-87ce-7c10a4e42e2b
> Are you using pam_ldap? ldap for user authorization?
>
> We just added the ability for samba to use ldap, out of the box.
I am using Kerberos for authentication; but I'm using LDAP for user
information.
(Though I get the impression that login is currently falling back to local
authentication; because I don't have a Kerberos ticket after I log in.)
But you are not use sssd for this. Anyways do you still believe you are
having SELinux issues?
12:06 a.m.
On Thu, 2012-04-12 at 22:55 -0400, Daniel J Walsh wrote:
On 04/12/2012 08:47 PM, Braden McDaniel wrote:
[snip]
> I am using Kerberos for authentication; but I'm using LDAP
for user
> information.
>
> (Though I get the impression that login is currently falling back to local
> authentication; because I don't have a Kerberos ticket after I log in.)
>
But you are not use sssd for this.
I am under the impression that I am using sssd.
Anyways do you still believe you are
having SELinux issues?
Since I haven't seen any more alerts, I don't think I am. If you are
sufficiently curious, I can unset authlogin_nsswitch_use_ldap and see
what happens.
--
Braden McDaniel <braden(a)endoframe.com>
9:31 a.m.
On 04/13/2012 01:06 AM, Braden McDaniel wrote:
On Thu, 2012-04-12 at 22:55 -0400, Daniel J Walsh wrote:
> On 04/12/2012 08:47 PM, Braden McDaniel wrote:
[snip]
>> I am using Kerberos for authentication; but I'm using LDAP for user
>> information.
>>
>> (Though I get the impression that login is currently falling back to
>> local authentication; because I don't have a Kerberos ticket after I
>> log in.)
>>
> But you are not use sssd for this.
I am under the impression that I am using sssd.
> Anyways do you still believe you are having SELinux issues?
Since I haven't seen any more alerts, I don't think I am. If you are
sufficiently curious, I can unset authlogin_nsswitch_use_ldap and see what
happens.
Basically in Fedora 16 we turned off the ability for apps that did getpw()
from being able to connect to the ldap port, by default. Turning that boolean
on, allows all domains that call getpw to connect to the ldap port. We turned
this off because sssd now connects to ldap if it is setup and apps calling
getpw talk to sssd rather then ldap. We have seen some daemons (samba) that
talk directly that we have broken with this change, but I believe the fixes
are going into Fedora now.
8:35 p.m.
On Fri, 2012-04-13 at 10:31 -0400, Daniel J Walsh wrote:
On 04/13/2012 01:06 AM, Braden McDaniel wrote:
> On Thu, 2012-04-12 at 22:55 -0400, Daniel J Walsh wrote:
[snip]
>> Anyways do you still believe you are having SELinux issues?
>
> Since I haven't seen any more alerts, I don't think I am. If you are
> sufficiently curious, I can unset authlogin_nsswitch_use_ldap and see what
> happens.
Basically in Fedora 16 we turned off the ability for apps that did getpw()
from being able to connect to the ldap port, by default. Turning that boolean
on, allows all domains that call getpw to connect to the ldap port. We turned
this off because sssd now connects to ldap if it is setup and apps calling
getpw talk to sssd rather then ldap. We have seen some daemons (samba) that
talk directly that we have broken with this change, but I believe the fixes
are going into Fedora now.
Well, I turned off authconfig_nsswitch_use_ldap; and I'm still not
seeing any alerts. Perhaps the alert I saw that recommended this was
one leftover from before the last relabel I did.
--
Braden McDaniel <braden(a)endoframe.com>
9:07 p.m.
On Fri, 2012-04-13 at 10:31 -0400, Daniel J Walsh wrote:
[snip]
Basically in Fedora 16 we turned off the ability for apps that did
getpw()
from being able to connect to the ldap port, by default. Turning that boolean
on, allows all domains that call getpw to connect to the ldap port. We turned
this off because sssd now connects to ldap if it is setup and apps calling
getpw talk to sssd rather then ldap. We have seen some daemons (samba) that
talk directly that we have broken with this change, but I believe the fixes
are going into Fedora now.
Is this such an example? I get this when using system-config-samba.
SELinux is preventing /usr/bin/python from open access on the chr_file urandom.
***** Plugin catchall_boolean (47.5 confidence) suggests *******************
If you want to allow users to login using a sssd server
Then you must tell SELinux about this by enabling the
'authlogin_nsswitch_use_ldap'boolean.
Do
setsebool -P authlogin_nsswitch_use_ldap 1
***** Plugin catchall_boolean (47.5 confidence) suggests *******************
If you want to enable reading of urandom for all domains.
Then you must tell SELinux about this by enabling the
'global_ssp'boolean.
Do
setsebool -P global_ssp 1
***** Plugin catchall (6.38 confidence) suggests ***************************
If you believe that python should be allowed open access on the urandom chr_file
by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep system-config-s /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:sambagui_t:s0-s0:c0.c1023
Target Context system_u:object_r:urandom_device_t:s0
Target Objects urandom [ chr_file ]
Source system-config-s
Source Path /usr/bin/python
Port <Unknown>
Host rail.endoframe.net
Source RPM Packages python-2.7.2-5.2.fc16.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.10.0-80.fc16.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Permissive
Host Name rail.endoframe.net
Platform Linux rail.endoframe.net 3.3.1-5.fc16.x86_64 #1
SMP Tue Apr 10 19:56:52 UTC 2012 x86_64 x86_64
Alert Count 2
First Seen Mon 16 Apr 2012 06:49:45 PM EDT
Last Seen Mon 16 Apr 2012 06:52:51 PM EDT
Local ID 331208b1-df87-4aa1-bddf-60ae4685f12d
Raw Audit Messages
type=AVC msg=audit(1334616771.522:793): avc: denied { open } for pid=16042
comm="system-config-s" name="urandom" dev="devtmpfs"
ino=1033 scontext=system_u:system_r:sambagui_t:s0-s0:c0.c1023
tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1334616771.522:793): arch=x86_64 syscall=open success=yes
exit=ECHILD a0=148c4d0 a1=0 a2=1ff a3=20 items=0 ppid=16041 pid=16042 auid=4294967295
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295
comm=system-config-s exe=/usr/bin/python subj=system_u:system_r:sambagui_t:s0-s0:c0.c1023
key=(null)
Hash: system-config-s,sambagui_t,urandom_device_t,chr_file,open
audit2allow
#============= sambagui_t ==============
#!!!! This avc can be allowed using one of the these booleans:
# authlogin_nsswitch_use_ldap, global_ssp
allow sambagui_t urandom_device_t:chr_file open;
audit2allow -R
#============= sambagui_t ==============
#!!!! This avc can be allowed using one of the these booleans:
# authlogin_nsswitch_use_ldap, global_ssp
allow sambagui_t urandom_device_t:chr_file open;
--
Braden McDaniel <braden(a)endoframe.com>
7:27 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/16/2012 10:07 PM, Braden McDaniel wrote:
On Fri, 2012-04-13 at 10:31 -0400, Daniel J Walsh wrote:
[snip]
> Basically in Fedora 16 we turned off the ability for apps that did
> getpw() from being able to connect to the ldap port, by default. Turning
> that boolean on, allows all domains that call getpw to connect to the
> ldap port. We turned this off because sssd now connects to ldap if it is
> setup and apps calling getpw talk to sssd rather then ldap. We have seen
> some daemons (samba) that talk directly that we have broken with this
> change, but I believe the fixes are going into Fedora now.
Yes, It certainly looks like we should allow sambagui_t to access the ldap
server without turning on the boolean.
Is this such an example? I get this when using system-config-samba.
SELinux is preventing /usr/bin/python from open access on the chr_file
urandom.
***** Plugin catchall_boolean (47.5 confidence) suggests
*******************
If you want to allow users to login using a sssd server Then you must tell
SELinux about this by enabling the 'authlogin_nsswitch_use_ldap'boolean.
Do setsebool -P authlogin_nsswitch_use_ldap 1
***** Plugin catchall_boolean (47.5 confidence) suggests
*******************
If you want to enable reading of urandom for all domains. Then you must
tell SELinux about this by enabling the 'global_ssp'boolean. Do setsebool
-P global_ssp 1
***** Plugin catchall (6.38 confidence) suggests
***************************
If you believe that python should be allowed open access on the urandom
chr_file by default. Then you should report this as a bug. You can generate
a local policy module to allow this access. Do allow this access for now by
executing: # grep system-config-s /var/log/audit/audit.log | audit2allow -M
mypol # semodule -i mypol.pp
Additional Information: Source Context
system_u:system_r:sambagui_t:s0-s0:c0.c1023 Target Context
system_u:object_r:urandom_device_t:s0 Target Objects urandom
[ chr_file ] Source system-config-s Source Path
/usr/bin/python Port <Unknown> Host
rail.endoframe.net Source RPM Packages
python-2.7.2-5.2.fc16.x86_64 Target RPM Packages Policy RPM
selinux-policy-3.10.0-80.fc16.noarch Selinux Enabled True
Policy Type targeted Enforcing Mode
Permissive Host Name rail.endoframe.net Platform
Linux rail.endoframe.net 3.3.1-5.fc16.x86_64 #1 SMP Tue Apr 10 19:56:52 UTC
2012 x86_64 x86_64 Alert Count 2 First Seen
Mon 16 Apr 2012 06:49:45 PM EDT Last Seen Mon 16 Apr
2012 06:52:51 PM EDT Local ID
331208b1-df87-4aa1-bddf-60ae4685f12d
Raw Audit Messages type=AVC msg=audit(1334616771.522:793): avc: denied {
open } for pid=16042 comm="system-config-s" name="urandom"
dev="devtmpfs"
ino=1033 scontext=system_u:system_r:sambagui_t:s0-s0:c0.c1023
tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1334616771.522:793): arch=x86_64 syscall=open
success=yes exit=ECHILD a0=148c4d0 a1=0 a2=1ff a3=20 items=0 ppid=16041
pid=16042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm=system-config-s exe=/usr/bin/python
subj=system_u:system_r:sambagui_t:s0-s0:c0.c1023 key=(null)
Hash: system-config-s,sambagui_t,urandom_device_t,chr_file,open
audit2allow
#============= sambagui_t ============== #!!!! This avc can be allowed
using one of the these booleans: # authlogin_nsswitch_use_ldap,
global_ssp
allow sambagui_t urandom_device_t:chr_file open;
audit2allow -R
#============= sambagui_t ============== #!!!! This avc can be allowed
using one of the these booleans: # authlogin_nsswitch_use_ldap,
global_ssp
allow sambagui_t urandom_device_t:chr_file open;
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+NYc4ACgkQrlYvE4MpobMCiwCgysm2rDbGq/aA2fA5ig7SIH1S
xo4An1A2gqtY3pRPEY2vuUraGB8CS5/A
=StFz
-----END PGP SIGNATURE-----
4:57 p.m.
On Tue, 2012-04-17 at 08:27 -0400, Daniel J Walsh wrote:
[snip]
Yes, It certainly looks like we should allow sambagui_t to access the
ldap
server without turning on the boolean.
Filed bug 813974: https://bugzilla.redhat.com/show_bug.cgi?id=813974
--
Braden McDaniel <braden(a)endoframe.com>
4427
days inactive
4434
days old
15 comments
3 participants
participants (3)
-
Braden McDaniel -
Daniel J Walsh -
Paul W. Frields