Bug 139692

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.

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
which
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.

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
anyways.

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!)

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.

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?

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:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0080

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.

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.

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
fsgid=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
tclass=rawip_socket

 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
/usr/libexec/xscreensaver/hacks/sonar

xscreensaver-extras-4.18-19
xscreensaver-base-4.18-19

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
rawipsocket?

Dan

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!

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.