Bug 13199 - GNOME desktop listens on many TCP sockets
GNOME desktop listens on many TCP sockets
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: ORBit (Show other bugs)
7.1
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Elliot Lee
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-06-28 18:18 EDT by Chris Evans
Modified: 2008-05-01 11:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-07-31 17:56:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Evans 2000-06-28 18:18:13 EDT
The default GNOME desktop, when fired up, listens on multiple TCP sockets.
Risks like that should be left to users who pick server class installs, not
desktop class installs!
.
Between GNOME-1.0 and GNOME-1.2, the GNOME team stopped gnome-session
listening on TCP with libICE. That's a step forward but the current
situation is exposure of libORBit code to the network.
.
Recent intense debate on gnome-list concluded with a large majority, that
listening on TCP sockets in default configuration is mad. The functionality
to risk ratio is _way_ over towards risk (even advanced GNOME users don't
need TCP listening panel applets).
.
Debian fix this by putting a global config directive in /etc/orbitrc.
However I'm not sure we can persue that. As Elliot Lee rightly points out,
libORBit might be used by something other than GNOME, which makes disabling
the ORB's TCP sockets less desirable.
.
Something definitely needs to be done, though..... I'd love to see RH7.0
take a step forward in the desktop security department.
Comment 1 David Mason 2000-06-28 21:09:13 EDT
Elliot, we have to give some sort of compromise on this issue. There is too much
traffic about it.. we need something.
Comment 2 Chris Evans 2000-07-17 19:31:08 EDT
Here's a thought.
Debian use /etc/orbitrc to disable listening sockets. We all agree that doing
this on a system-wide scale is a little excessive, however.
So why not include a safe .orbitrc in /etc/skel? This gets us the following
- A safe default for all desktop users
- Any system CORBA application will be able to use TCP sockets unimpeded
(assuming of course it correctly doesn't run under a user account)
Comment 3 Matthew Kirkwood 2000-07-18 10:49:04 EDT
For what it's worth (and Elliot's silence would appear to indicate that he
doesn't think any of this discussion is worth much) as an ORBit user (outside of
GNOME) I'd much rather it was disabled.

We have fairly granular CORBA services on server machines, and very few of them
need to be exposed to the outside world.
Comment 4 Elliot Lee 2000-07-18 12:49:47 EDT
Matthew,

Your strong opinion is already well known. However, I don't think it counts as
representative of the user base. :)
Comment 5 Glen Foster 2000-07-18 15:51:14 EDT
This defect is considered MUST-FIX for Winston Beta-5
Comment 6 Glen Foster 2000-07-21 14:07:52 EDT
This defect has been re-classified as MUST-FIX for Winston Gold-release
Comment 7 Chris Evans 2000-07-21 17:54:44 EDT
Here's another datapoint
- A recent Helix GNOME update has disabled TCP listening ORBit sockets. The
mechanism is /etc/orbitrc.

To be honest I suddenly realised that maybe the number of people pissed at
listening by default, exceeds the number of people who would be inconvenienced
by it being turned off be default.
Why not use the public BETA, BETA-5 as a testing ground? Disable listening
sockets in /etc/orbitrc, like Debian and Helix, and see what kickback you get.
Comment 8 Chris Evans 2000-07-24 17:28:04 EDT
Tick... tick... tick... that's the countdown to the public beta ;-)
Comment 9 Chris Evans 2000-07-31 17:56:06 EDT
Seems to be fixed in BETA5, nice one.
For the record, I've fired up the KDE pre-2.0 desktop. It still listens on no
TCP sockets by default which is good.

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