Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list
I'm relatively new to system administration. I picked Debian over FreeBSD, Ubuntu, Fedora and a few other systems for a number of reasons, one of these being its reputation for internal consistency. This issue is making me question that reputation. The opportunity to avoid having to monkeypatch things is one of Debian's great attractions, but it's failing in this case. Rootkits aren't to be trifled with. Sysadmins' time shouldn't be trifled with either. Also, given that the first thing a security-conscious newbie sysadmin is going to do is to learn how to use a distro's security tools, including its rootkit detection packages. It's very hard for a new user to tell, on seeing, say, chkrootkit throw an error about /lib/init/rw/.ramfs , whether it's a false positive or not. That's not good for the learning curve, which in turn isn't good for Debian adoption. Please could the initscripts maintainers do the decent thing and: *stop using hidden files that look like trojans, * OR, failing that, amend the Debian documentation to explicitly allow such files to be used in the ways reported in this bug, and co-ordinate a patch with the chkrootkit maintainers? Debian users will thank you for solving this problem :) Let me be the first: many thanks in advance, Sam
Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list
Is this bug going to be worked? Either by initscripts or chrootkit? Does it go down as a DebianWontfixDueToInternalBickering and leave the user to hack together a workaround? If it's the latter, then http://stereo.lu/chkrootkit-finds-libinitrwramfs-on-debian-etch has some information that will be useful. Regards Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list
I'm here because both 'tiger' and 'chkrootkit' are reporting potential problems. From tiger: # Checking installed files against packages... --WARN-- [lin001w] File `/lib/init/rw/.mdadm/md3-uevent' does not belong to any package. --WARN-- [lin001w] File `/lib/init/rw/.mdadm/md2-uevent' does not belong to any package. --WARN-- [lin001w] File `/lib/init/rw/.mdadm/md1-uevent' does not belong to any package. --WARN-- [lin001w] File `/lib/init/rw/.mdadm/md0-uevent' does not belong to any package. --WARN-- [lin001w] File `/lib/init/rw/.ramfs' does not belong to any package. From chkrootkit: Searching for suspicious files and dirs, it may take a while... /lib/init/rw/.mdadm /lib/init/rw/.ramfs /lib/init/rw/.mdadm I may be wrong, but it's my opinion that tiger and chkrootkit are right to report these files and that this is not a bug in them. Reassigning this bug to chkrootkit will not fix the the fact that tiger reports these files as not belonging to any package. Like others, I became very suspicious when I first found a hidden directory under /lib.
Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list
"chkrootkit is reporting some files and dirs as suspicious: `.packlist', `.cvsignore', etc. These are clearly false positives. Can't you ignore these? Ignoring some files and dirs could impair chkrootkit's accuracy. An attacker might use this, since he knows that chkrootkit will ignore certain files and dirs." http://www.chkrootkit.org/faq/ i don´t think that it will be *fixed*. the reasons above are clear and as far as I may mention: it´s up to those developers, who use hidden files in uncomfortable places. Unfortunately it seems there are more developers using dot-file-flags... but actually the ".ramfs" is the only file which is declared as "suspicous" in my daily chkrootkit report. Am I wrong? cheers sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403863: [Pkg-sysvinit-devel] Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list
Henrique de Moraes Holschuh wrote: The bigger problem is that there's other stuff in /lib/init that doesn't agree with the FHS.Unfortunately, the FHS doesn't have /libexec either... No. The big problem is that, AFAWK, the FHS doesn't have /run or anything else that is usable for the initrw ... [Nice explanation deleted] The only reason I didn't tag this wontfix is that I also agree we should get rid of .ramfs if we can. I hate failure-prone solutions like the use of "flag files" like .ramfs. Yep. It also looks remarkably like something left by a break-in or rootkit. Correct me if I'm wrong, but if this file is simply a flag that a ramfs is mounted there, can't you get the equivalent information from stat() or statvfs()? There's always /etc/mtab, though one might not trust it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403863: [Pkg-sysvinit-devel] Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list
On Mon, 01 Jan 2007, Greg Kochanski wrote: > >On Sun, 31 Dec 2006, Greg Kochanski wrote: > >>According to that document, /lib is reserved for "shared library images > >>needed to boot the system and run the commands in the root filesystem". > > > >This is a bogus description of lib *on systems where libexec is not used*. > > It's not a bogus description, it's a direct quote from Debian > documentation. If it's wrong/bad, propose a patch against the FHS. Debian documentation is often wrong [as in it does not reflect reality because of other reasons than bugs], outdated, and all that crap as usual. The truth is that Debian just "mostly" follows the FHS. From time to time this is dealt with and Debian adjusts more to the FHS, or the FHS adds this and that to better allow for Debian system needs. It is a continuous process. I am not defending this. I am stating that it is the reality, not that it is desireable. > In particular, the FHS goes on to say "Only the shared libraries > required to run binaries in /bin and /sbin may be here." That's pretty > clear English, as far as I'm concerned. I never said you had gotten the FHS wrong. > The bigger problem is that there's other stuff in /lib/init that > doesn't agree with the FHS.Unfortunately, > the FHS doesn't have /libexec either... No. The big problem is that, AFAWK, the FHS doesn't have /run or anything else that is usable for the initrw partition, and that adding anything to / is non-trivial and requires a ruling of the TC in the Debian side. So the sysvinit team got hold of a namespace that is ours and technically sound (/lib/init) as it is local-system-specific and required to be available at the time /sbin/init is run, and bypassed all the bickering in the Debian side. If the FHS can mandate /run, we will switch to it. If it requires Debian and others to implement it first, then it will probably not happen anytime soon, as last time I checked, the sentiment among the sysvinit team is that we have better ways to waste our time than doing monkey-headbutting against other DDs to deploy /run. And, unlike /lib, placing the initrw partition on /etc would be just Wrong, /boot and /mnt are out-of-limits, /tmp is unusable for initrw partitions, etc. The only reason I didn't tag this wontfix is that I also agree we should get rid of .ramfs if we can. I hate failure-prone solutions like the use of "flag files" like .ramfs. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403863: [Pkg-sysvinit-devel] Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list
Henrique de Moraes Holschuh wrote: On Sun, 31 Dec 2006, Greg Kochanski wrote: According to that document, /lib is reserved for "shared library images needed to boot the system and run the commands in the root filesystem". This is a bogus description of lib *on systems where libexec is not used*. It's not a bogus description, it's a direct quote from Debian documentation. If it's wrong/bad, propose a patch against the FHS. See http://www.pathname.com/fhs/ and http://www.pathname.com/fhs/pub/fhs-2.3.html . In particular, the FHS goes on to say "Only the shared libraries required to run binaries in /bin and /sbin may be here." That's pretty clear English, as far as I'm concerned. Well, we could just add libexec and move a ton of crap from lib to libexec. I also dislike .files ANYWHERE outside of user dirs, but lots of other stuff uses them too as it was pointed out to me sometime ago in -devel. The bigger problem is that there's other stuff in /lib/init that doesn't agree with the FHS.Unfortunately, the FHS doesn't have /libexec either... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403863: [Pkg-sysvinit-devel] Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list
On Sun, 31 Dec 2006, Greg Kochanski wrote: > According to that document, /lib is reserved for "shared library images > needed to boot the system and run the commands in the root filesystem". This is a bogus description of lib *on systems where libexec is not used*. Well, we could just add libexec and move a ton of crap from lib to libexec. I also dislike .files ANYWHERE outside of user dirs, but lots of other stuff uses them too as it was pointed out to me sometime ago in -devel. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list
Sorry! Please note, that if I was insulting anything, it was a file, not any person. Please don't be quite so testy! I should have said "Probably violates the Debian rules for the filesystem hierarchy standard, as shown on http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#LIBESSENTIALSHAREDLIBRARIESANDKERN " According to that document, /lib is reserved for "shared library images needed to boot the system and run the commands in the root filesystem". My understanding is that /lib/init/rw/.ramfs is not a shared library image, so it probably shouldn't be there. If there *is* a good reason, that's one thing, but please stick to the technical issues. Petter Reinholdtsen wrote: [Greg Kochanski] The file /lib/init/rw/.ramfs is created, presumably by initscripts. It's not in the package list, and that's not at all a good place to dynamically create a file. Not to mention, putting a hidden file under /lib is pretty low-class. I did not quite get what problem you are describing. "not a good place" and "pretty low-class" do not seem like descriptions of a bug nor a problem to me. They more visualises your personal values, and I'm not sure how it is relevant for the boot system. /lib/init/rw/.ramfs is created by the initscripts to flag that the directory is a ramfs. It is intentional hidden to avoid name conflict with anything we want to store there. Friendly, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403863: [Pkg-sysvinit-devel] Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list
On Wed, 20 Dec 2006, Petter Reinholdtsen wrote: > [Greg Kochanski] > > The file /lib/init/rw/.ramfs is created, presumably by initscripts. > > It's not in the package list, and that's not at all a good place to > > dynamically create a file. Not to mention, putting a hidden file > > under /lib is pretty low-class. > > I did not quite get what problem you are describing. "not a good > place" and "pretty low-class" do not seem like descriptions of a bug > nor a problem to me. They more visualises your personal values, and > I'm not sure how it is relevant for the boot system. Well, we *cannot* add the file to the package list, so that's a NAK (won't fix) for that part. dpkg doesn't allow us to do it even if we wanted to, which we don't. That doesn't mean we should be using a .ramfs file as a marker, though. If we could ask the kernel directly, that would be MUCH better. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list
[Greg Kochanski] > The file /lib/init/rw/.ramfs is created, presumably by initscripts. > It's not in the package list, and that's not at all a good place to > dynamically create a file. Not to mention, putting a hidden file > under /lib is pretty low-class. I did not quite get what problem you are describing. "not a good place" and "pretty low-class" do not seem like descriptions of a bug nor a problem to me. They more visualises your personal values, and I'm not sure how it is relevant for the boot system. /lib/init/rw/.ramfs is created by the initscripts to flag that the directory is a ramfs. It is intentional hidden to avoid name conflict with anything we want to store there. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list
Package: initscripts Version: 2.86.ds1-36 Severity: normal The file /lib/init/rw/.ramfs is created, presumably by initscripts. It's not in the package list, and that's not at all a good place to dynamically create a file. Not to mention, putting a hidden file under /lib is pretty low-class. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages initscripts depends on: ii debianut 2.17Miscellaneous utilities specific t ii e2fsprog 1.39+1.40-WIP-2006.11.14+dfsg-1 ext2 file system utilities and lib ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii lsb-base 3.1-22 Linux Standard Base 3.1 init scrip ii mount2.12r-15Tools for mounting and manipulatin ii sysvinit 2.86.ds1-36 System-V-like utilities Versions of packages initscripts recommends: ii psmisc22.3-1 Utilities that use the proc filesy -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
