Bug 111640 - RHEL3 U3: pidentd is missing from RHES3
RHEL3 U3: pidentd is missing from RHES3
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: distribution (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: dff
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-07 09:32 EST by Bernd Bartmann
Modified: 2007-11-30 17:06 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-02 01:02:55 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 Bernd Bartmann 2003-12-07 09:32:19 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031114

Description of problem:
pidentd is missing from RHES3

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


How reproducible:
Always

Steps to Reproduce:
1. where is pidentd?
2.
3.
    

Additional info:
Comment 1 agt 2003-12-16 18:32:07 EST
I see this on AS and WS as well - no pidentd packages.
Comment 2 Eido Inoue 2003-12-17 11:56:54 EST
changing package
Comment 3 Eido Inoue 2003-12-17 12:30:56 EST
changing yet again
Comment 4 Thierry Linder 2004-02-10 09:39:44 EST
Thanks to inform me when the pidentd package is available under RH WS 
3.0
Comment 5 Larry Troan 2004-04-12 08:13:41 EDT
Issue Tracker 36998 opened as sev 3 by ltroan@redhat.com
Comment 6 Larry Troan 2004-04-12 08:22:41 EDT
From http://freshmeat.net/projects/pidentd/ regarding pidentd:

Pidentd v3 is a much improved version of the original Ident daemon
both in terms of speed, code quality and features. Features include
multithreading, a "configure" script, startup autodetection, much
clearer/rewritten C code, doesn't run as root after startup, has a
configuration file and can be started from /etc/inittab (on systems
using a SysV init).

Adrian, does version 3 solve the security problem that caused pidentd
to be pulled from the RHEL3 package list?
Comment 8 Larry Troan 2004-04-12 08:36:38 EDT
Bernd, agt, Thierry, Rick,
Could one of you PLEASE provide me with a business justiification as
to why this package should be added back into RHEL3 (makes it a lot
easier for me when approaching RH management). 

For example, from the pidentd home page:
This is a program that implements the RFC1413 identification server.
It was very much inspired by Dan Bernstein's original 'authd' (but
unlike that program doesn't use 'netstat' to get some of the
information) It uses the kernel information directly. (And is due to
that fact a lot faster). Dan has now written another version of the
'authd' daemon that uses his 'kstuff' to read the kernel information.
Unlike that daemon, this will use only normally available kernel
access functions (and is due to that more limited in the different
machines it support). Please note that this daemon used to be called
pauthd but has changed name to better reflect what it does (and to
conform to the new RFC).

NOTE THAT pidentd-3.0.16-1 IS INCLUDED IN THE Fedora core1 DISTRIBUTION...
Comment 10 Larry Troan 2004-04-12 11:22:52 EDT
Adrian, Donald,
Customer is asking what security exposure caused us to remove the
package from RHEL3. Can you help me with the specifics?

My guess would be that the latest pidentd doesn't run as root after
startup as it did before. Also, this new package only uses normally
available kernel access functions.
Comment 11 Eido Inoue 2004-04-12 12:19:56 EDT
I was not made aware of any security problems regarding the current
pidentd... other than the implied privacy and information gleening
that could be obtained by running pidentd in a non-crypt way.

If pidentd is missing from a RHEL3 distro then the component should be
changed to "distribution", as the reason it's missing is not due to
pidentd, but do to its intentional/non-intentional ommission from comps.
Comment 12 Larry Troan 2004-04-12 15:41:03 EDT
The person commenting this was a security exposure was referring to
the fact that anyone can query the ident db and find out every process
running on the system. This would give a hacker the ability to focus
on what cracking mechanisms he/she intended to employ.... making it
easier to find holes.   
Comment 13 Eido Inoue 2004-04-12 16:02:47 EDT
Comment 12: in the default configuration, the public reply that
pidentd returns is encrypted; the information can only be decrypted by
the sysadmin that has access to the pidentd daemon. You'd have to
intentionally change the configuration to provide a non-secure version.

Thus, in the default distributed configuration, it isn't possible for
random people to gleen process information. (well, they RECEIVE the
process information, but it's encrypted-- thus the security of pident
rests on the strength and security of the encryption-- of which there
haven't been any known problems)
Comment 24 Jay Turner 2004-09-02 01:02:55 EDT
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2004-363.html

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