Bug 139692 - Sonar hangs Machine running strict SELinux policy
Summary: Sonar hangs Machine running strict SELinux policy
Alias: None
Product: Fedora
Classification: Fedora
Component: xscreensaver
Version: 3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-17 16:03 UTC by Daniel Walsh
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2005-10-24 06:28:42 UTC

Attachments (Terms of Use)

Description Daniel Walsh 2004-11-17 16:03:53 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020

Description of problem:
SELinux policy does not allow users to create raw sockets, this causes
and AVC message, usually when this happens I find my laptop hung and
have to press the reset button to get it back.

Can you change sonar to default to use the simulation instead of
attempting to do a ping.


Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run sonar on an Strict SELinux box

Actual Results:  Avc message in /var/log/message denying access to
create a raw socket,

occasional system hang.

Expected Results:  No AVC message, no hang

Additional info:

Comment 1 Jamie Zawinski 2005-02-28 03:35:29 UTC
If the sonar executable is not setuid, then the socket() call will fail and
sonar will silently proceed to run in "simulation" mode.  Why is that a problem?

I believe, however, that it is safe for sonar to be installed as setuid (at
least as safe as it is that /bin/ping is setuid.)  That would make ping-mode
work for all users.

Comment 2 Daniel Walsh 2005-02-28 13:13:10 UTC
SELinux triggers an error message  saying that a user app tried to open a raw
socket.  We have two choices, one allow it.  This is a bad idea since a trojan
app could start listening for packets on the network.  Two would be dontaudit it
would eliminate the chance of us finding a trojan app running as a user.  I just
want it defaulted to simulation mode for Fedora/RHEL releases.  

Setting the APP setuid would be a disaster from a security perspective.  You
want small easily studdied applications to be setuid,  Larget X-Windows apps
should almost never be setuid.

Comment 3 Colin Walters 2005-02-28 20:51:48 UTC
I'd just remove the setuid bit on the screensaver, and thus it'll fail DAC
checks and not hit SELinux.

I'm sure sysadmins would hate a screensaver that randomly pings other machines

Comment 4 Jamie Zawinski 2005-02-28 21:02:28 UTC
Daniel Walsh wrote:
> Setting the APP setuid would be a disaster from a security perspective. 
> You want small easily studdied applications to be setuid, 
> Larget X-Windows apps should almost never be setuid.

I totally agree, but there's no other way to make sonar work properly.
Sonar is small, and is as secure as I could make it.  It drops privs
immediately after startup: it connects to X, opens the socket, then 
setuid(getuid()).  If you can think of a way to make it more secure,
I'd love to hear it!

Colin Walters wrote:
> I'd just remove the setuid bit on the screensaver, and thus it'll fail DAC
> checks and not hit SELinux.

But "sonar" is not setuid in the redhat install.
Or does something happen differently because its parent process
"xscreensaver" is setuid (and has already discarded privs?)

> I'm sure sysadmins would hate a screensaver that randomly pings other
> machines anyways.

Actually, you'd be surprised: sonar is *extremely* popular with sysadmins.
They like running it in machine rooms and impressing visitors and the boss by
saying "look, that's our network."  (I was surprised too, but I get a lot of
mail about it!)

Comment 5 Colin Walters 2005-03-01 00:03:38 UTC
I'm nervous about anything with an X connection and extra privileges in the
desktop session.

Anyways, we need to investigate whether or not it would normally be able to open
the raw socket without SELinux in the picture.  Perhaps this is a case where the
DAC checks come second?

Perhaps xscreensaver isn't dropping privileges well enough - e.g. if it retains
gid 0 or doesn't call setgroups.

Comment 6 Jamie Zawinski 2005-03-01 00:19:26 UTC
xscreensaver does setgid(getgid()) then setuid(getuid())
when geteuid() != getuid() || getegid() != getgid().
After that, if getuid() == 0, it switches to user "nobody".

It never calls setgroups().  Does it need to?

The code is in xscreensaver/driver/setuid.c if you want to take a look.

However, since Red Hat is PAM-driven, I think there's no reason for the
xscreensaver executable to be setuid at all.  That's only needed when using
shadow passwords in a non-PAM world.  Right?

Comment 7 Colin Walters 2005-03-01 15:39:27 UTC
The canonical way to drop all privileges is setgroups, setgid, setuid.  If you
don't call setgroups the process will retain supplementary group ids associated
with the uid, e.g. on Fedora:

[root@nexus walters]# groups root
root : root bin daemon sys adm disk wheel

Here's an example of this flaw:

Anyways, upon quick investigation, you are right; xscreensaver is apparently not
setuid on Fedora, thankfully.  And neither is the sonar executable.

So the mystery remains why we're getting avc denials from SELinux; my tests
indicate that creating a raw socket is denied by DAC (running as unconfined_t):

walters@nexus> strace -esocket /usr/libexec/xscreensaver/hacks/sonar
socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = -1 EPERM (Operation not permitted)

Someone with a strict policy machine will have to investigate.  My guess however
is that somewhere in the socket code we're doing LSM checks before DAC or something.

Although, my tests are on a rawhide machine; things could be different in FC3
now that I think about it.

Comment 8 Ray Strode [halfline] 2005-03-01 17:54:15 UTC
IIRC, the --without-setuid-hacks configure option (or whatever it's called) was
added after FC3, but I believe the default is to not setuid the binaries anyway,
so I don't think they should be setuid in FC3.

Comment 9 Daniel Walsh 2005-03-08 17:00:37 UTC
I just recreated the problem on a rawhide machine.  Logged in as a
unprived user, fired up screensaver/sonar in preview mode and got

type=KERNEL msg=audit(1110300780.327:11287824): syscall=102 exit=-13
a0=1 a1=bff356f0 a2=c00009 a3=91ce975 items=0 pid=14528 loginuid=-1
uid=3268 gid=3268 euid=3268 suid=3268 fsuid=3268 egid=3268 sgid=3268
type=KERNEL msg=audit(1110300780.327:11287824): avc:  denied  { create
} for  pid=14528 exe=/usr/libexec/xscreensaver/hacks/sonar
scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t

 ls -l /usr/bin/xscreensaver
-rwxr-xr-x  1 root root 218844 Feb 25 15:39 /usr/bin/xscreensaver

ls -l /usr/libexec/xscreensaver/hacks/sonar
-rwxr-xr-x  1 root root 44492 Feb 25 15:39


Comment 10 Daniel Walsh 2005-04-21 14:51:16 UTC
According to Stephen Smalley, this is happening because the MAC checks are
happening before the DAC checks.  This is caused because of the away sockets are
implemented in the Kernel and would be very combersome to change the way the
code works.  Would it be possible to add a if(getuid() != 0 ) dont try the


Comment 11 Jamie Zawinski 2005-04-21 19:43:54 UTC
Yeah, I guess I could do that in sonar.

Is it safe for me to assume that there are no Unix systems on which raw sockets
can be created when getuid() != 0 ?

But if a non-root program trying to make a raw socket really does hang the
machine, that's still a pretty bad DoS!

Comment 12 Colin Walters 2005-05-03 22:02:06 UTC
There are two separate issues here:

1) A (spurious) avc denial message is generated; your getuid() != 0 should
workaround that.
2) sonar hanging the machine.  We don't have data on why this is happening; in
particular we don't know if it's actually related to the permission denial on
the socket or not.  My strong suspicion is "not", and it's actually an X bug.  

Note You need to log in before you can comment on or make changes to this bug.