Bug 111640
| Summary: | RHEL3 U3: pidentd is missing from RHES3 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Bernd Bartmann <bernd.bartmann> |
| Component: | distribution | Assignee: | dff <dff> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | agt, brian.b, havill, ltroan, rick.stern, summer, tao |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-09-02 05:02:55 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I see this on AS and WS as well - no pidentd packages. changing package changing yet again Thanks to inform me when the pidentd package is available under RH WS 3.0 Issue Tracker 36998 opened as sev 3 by ltroan 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? 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... 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. 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. 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 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) 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 |
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: