Package: lsof Version: 4.74.dfsg.3-2 Severity: normal
i think it may be dangerours to change this settings for sarge. It looks like with this flag set ntop won't work and maybe other 00README: >You should carefully consider the implications of using the default >security mode. When lsof is compiled in the absence of the >HASSECURITY definition, anyone who can execute lsof may be able to >see the presence of all open files. This may allow the lsof user >to observe open files -- e.g., log files used to track intrusions >-- whose presence you would rather not disclose. > Customize: >When HASSECURITY is enabled, you may also define HASNOSOCKSECURITY. > >When both are defined, no one but root may list all of anyone else's >open files -- only their own open files -- but anyone may list >anyone else's open socket files. > >This option is useful with ntop (http://www.ntop.org). > this could cause RC bugs. ntop does not depends on lsof (i will check just in case it is missing from teh debian package) but: alsa-base tiger tct netatalk irssi-scripts debian-goodies dancer-services alsa-base does and i won't have time to check them all before sarge (maybe even etch :) Also a problem i have not found out : there is a warning >lsof: WARNING: can't stat() ext3 file system /dev/.static/dev > Output information may be incomplete. when ran as a simple user. But lsof -h: Anyone can list all files; /dev warnings disabled; kernel ID check disabled. running lsof as root , not process access /dev/.static* so i am a bit out of luck why lsof try to access it and why it warns about a file in /dev ! This is the directory where udev store the static file for device not supporting sysfs yet. Maybe i misundesrtood and warndevices is for access to the device files themselves and not the directory inside dev ... And i am against blacklisting such files. A rootkit could put its own there . Well if it is out of luck,mdadmin have the same problem, i will see how they manage to avoid scanning the whole /dev tree but maybe lsof dev have their own opinion on the issue (other than using a cache so the warnign only happens once which is hackish and had security issues : lsof is a security tool , i prefer warnings than missing alerts !) Errata : sorry i won't rewrite the full bug report ... i foudn that it comes from /proc/mounts >rootfs / rootfs rw 0 0 >/dev/root / ext3 rw 0 0 >/dev/root /dev/.static/dev ext3 rw 0 0 >none /dev tmpfs rw 0 0 so i finally found out it comes from dmnt.c. Well and from the 00README : >Cautions >======== > >Lsof is a tool that is closely tied to the UNIX operating system >version. It uses header files that describe kernel structures and >reads kernel structures that typically change from OS version to >OS version, and even within a version as vendor patches are applied. > >DON'T TRY TO USE AN LSOF BINARY, COMPILED FOR ONE UNIX OS VERSION, >ON ANOTHER. VENDOR PATCHES INFLUENCE THE VERSION IDENTITY. > >On some UNIX dialects lsof versions may be even more restricted by >architecture type. > >The bottom line is use lsof where you built it. If you intend to >use a common lsof binary on multiple systems, make sure all systems >run exactly the same OS version and have exactly the same patches. and also: 00XCONFIG >Marty says: > > "I used this to successfully compile (lsof) on the same machine > for (Linux) 2.0.30 and 2.1.42. (I normally don't bring up a > 2.1.42 machine all the time). Also it (the 2.0.30 system) > doesn't have much storage and compiles on it are slow. > > Set LSOF_VERS if it's not the (version of the) current system. > (Actually, you should get the version out of include/linux/version.h.) > > Define LINUX_KERNEL to (the path) where the kernel sources > are (located). (No longer necessary as of lsof revision 4.53.) > > This should work on most systems; they put a kernel in > /usr/src/linux, which is the default. > > Now I can just do: > > LINUX_KERNEL=/some/other/kernel LSOF_VERS=2142 ./Configure linux > Does it really use the kernel headers instead of the glibc ones ? Reading the Configure and executing it, it looks like it does not ... Maybe this comment could be updated to replace "OS VERSION" by libc version ... (as the same kernel can be compiled with different libc6 this looks misleading as lsof from sarge would then break on woody even if the same kernel is used ...) Does lsof really need to access the kernel outside of the syscall defined and marshalled in glibc headers ? Or is LSOF_VERS only used for Configure to disable extensions ? I am really wondering how lsof could work if build from the kernel header data not known to the system libc ... (especially since this package is build after 2.6 from lsof -h ) Any input from you would help me avoid any more misleading judgements :) I saw comments about cahe security issues there but it looks like in the default configuration they are not used (i cannot find the cache on my box and the debian rules does not use its compilaiton flags). Else congratulation to have found out it did not need setuid. The documentation could not be more confusing: >When lsof needs to read /proc file system entries, it must be >installed with modes that make its effective user identifier root >when it runs -- i.e., it must be setuid-root. If lsof must be >installed setuid-root (only the AIX 5L, PSTAT-based HPUX, and >/proc-based Linux, ports need such power.), then access to memory >devices is automatic (or not needed in the case of /proc-based >Linux). from this one could tell it needs setuid (access to /proc) and not (does not need access to memory devices. Did i guessed right from the fact that it works well on debian without the setuid and without our memory devices being word readable that: >only the AIX 5L, PSTAT-based HPUX, and >/proc-based Linux, ports need such power. is wrong ? Greetings Alban -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11-rc5 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages lsof depends on: ii libc6 2.3.4-2 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
