Debian Bug report logs - #403863
initscripts: Stray file /lib/init/rw/.ramfs not in package list

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Greg Kochanski <gpk@kochanski.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: initscripts: Stray file /lib/init/rw/.ramfs not in package list

Date: Wed, 20 Dec 2006 08:09:32 +0000

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.17                            Miscellaneous utilities specific t
ii  e2fsprog 1.39+1.40-WIP-2006.11.14+dfsg-1 ext2 file system utilities and lib
ii  libc6    2.3.6.ds1-8                     GNU C Library: Shared libraries
ii  lsb-base 3.1-22                          Linux Standard Base 3.1 init scrip
ii  mount    2.12r-15                        Tools for mounting and manipulatin
ii  sysvinit 2.86.ds1-36                     System-V-like utilities

Versions of packages initscripts recommends:
ii  psmisc                        22.3-1     Utilities that use the proc filesy

-- no debconf information

Message #10 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: Greg Kochanski <gpk@kochanski.org>, 403863@bugs.debian.org

Subject: Re: Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list

Date: Wed, 20 Dec 2006 10:50:39 +0100

[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

Message #15 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Petter Reinholdtsen <pere@hungry.com>, 403863@bugs.debian.org

Cc: Greg Kochanski <gpk@kochanski.org>

Subject: Re: [Pkg-sysvinit-devel] Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list

Date: Sun, 24 Dec 2006 02:44:42 -0200

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

Message #20 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Greg Kochanski <gpk@kochanski.plus.com>

To: Petter Reinholdtsen <pere@hungry.com>

Cc: Greg Kochanski <gpk@kochanski.org>, 403863@bugs.debian.org

Subject: Re: Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list

Date: Sun, 31 Dec 2006 13:04:36 +0000

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,

Message #25 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: gpk@kochanski.org, 403863@bugs.debian.org

Cc: Petter Reinholdtsen <pere@hungry.com>

Subject: Re: [Pkg-sysvinit-devel] Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list

Date: Sun, 31 Dec 2006 14:48:22 -0200

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

Message #30 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Greg Kochanski <gpk@kochanski.plus.com>

To: Henrique de Moraes Holschuh <hmh@debian.org>

Cc: gpk@kochanski.org, 403863@bugs.debian.org, Petter Reinholdtsen <pere@hungry.com>

Subject: Re: [Pkg-sysvinit-devel] Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list

Date: Mon, 01 Jan 2007 12:32:58 +0000

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...

Message #35 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: gpk@kochanski.org

Cc: 403863@bugs.debian.org, Petter Reinholdtsen <pere@hungry.com>

Subject: Re: [Pkg-sysvinit-devel] Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list

Date: Mon, 1 Jan 2007 10:58:40 -0200

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

Message #40 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Greg Kochanski <gpk@kochanski.plus.com>

To: Henrique de Moraes Holschuh <hmh@debian.org>

Cc: gpk@kochanski.org, 403863@bugs.debian.org, Petter Reinholdtsen <pere@hungry.com>

Subject: Re: [Pkg-sysvinit-devel] Bug#403863: initscripts: Stray file /lib/init/rw/.ramfs not in package list

Date: Mon, 01 Jan 2007 16:47:23 +0000

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.

Message #45 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Michael Holzt <debian-bugreports@michael.holzt.de>

To: 403863@bugs.debian.org

Subject: Re: Cron <root@stfu> test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily

Date: Fri, 19 Jan 2007 12:48:53 +0100

I just found this bug report and i would like to add to the "It also looks
remarkably like something left by a break-in or rootkit.". In fact the
chkrootkit package _does_ warn about this file and identifies it as a
possible rootkit:

> /etc/cron.daily/chkrootkit:
> The following suspicious files and directories were found:
> /lib/init/rw/.ramfs

As chkrootkit also warned about two other suspicios findings, this really
scared the hell out of me. So if even chkrootkit finds this file wrong,
please get rid of it. Or if you must have it there, please contact the
chkrootkit maintainer to have this file excluded from checking.


Regards
Michael

-- 
      It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

Message #50 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Chris Samuel <chris@csamuel.org>

To: 403863@bugs.debian.org

Subject: Re: Cron <root@stfu> test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily

Date: Tue, 13 Feb 2007 21:18:51 +1100

[Message part 1 (text/plain, inline)]

On Fri, 19 Jan 2007, Michael Holzt wrote:

> I just found this bug report and i would like to add to the "It also looks
> remarkably like something left by a break-in or rootkit.". In fact the
> chkrootkit package _does_ warn about this file and identifies it as a
> possible rootkit:

Having just upgraded my webserver to Edgy I got exactly this warning which 
sent a chill down my spine.

The reason is that chkrootkit will flag any file under /lib (amongst other 
places) that starts with a . (along with other patterns).

So I'd just like to echo that it would be nice if this file was renamed to 
something that didn't give chkrootkit the heebie jeebies.. :-)

cheers,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP

[Message part 2 (application/pgp-signature, inline)]

Message #55 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Chris Samuel <chris@csamuel.org>

To: 403863@bugs.debian.org

Subject: Re: Cron <root@stfu> test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily

Date: Tue, 13 Feb 2007 21:25:02 +1100

[Message part 1 (text/plain, inline)]

On Tue, 13 Feb 2007, Chris Samuel wrote:

> Having just upgraded my webserver to Edgy I got exactly this warning which
> sent a chill down my spine.

Mea culpa - I mean Etch!

return -ETOOMANYDISTROS;

-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP

[Message part 2 (application/pgp-signature, inline)]

Message #62 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Binzberger Viktor <bviktor-nos_pam--@freemail.hu>

To: 403863@bugs.debian.org

Subject: Re: Cron <root@stfu> test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily

Date: Sun, 25 Mar 2007 12:05:23 +0200

Dear all,

I'm using Etch, and among others, I use tiger + chkrootkit to keep track 
of potential problems on my servers. I consider this to be a pretty 
standard configuration. The problem is that I get the following false 
positive alarms every day from chkrootkit:

The following suspicious files and directories were found:
/lib/init/rw/.mdadm
/lib/init/rw/.ramfs

Now this means that your approach is inconsistent with the use of 
standard security tools within the same distribution. I'd like to ask 
you to EITHER reconsider this strange new policy of putting hidden files 
under /lib OR provide and maintain a patched version of chrootkit in the 
distribution . Please, understand that I _don't_ want to recompile 
chkrootkit, and also don't want to write a wrapper around it to supress 
these messages, and I suspect that I'm not alone with this desire.

Cheers,
Viktor

Message #67 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Binzberger Viktor <bviktor-nos_pam--@freemail.hu>, 403863@bugs.debian.org

Subject: Re: [Pkg-sysvinit-devel] Bug#403863: Cron <root@stfu> test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily

Date: Mon, 26 Mar 2007 00:27:52 -0300

reassign 403863 chkrootkit
severity 403863 wishlist
retitle 403863 chkrootkit: please remove known false positives
thanks

On Sun, 25 Mar 2007, Binzberger Viktor wrote:
> The following suspicious files and directories were found:
> /lib/init/rw/.mdadm
> /lib/init/rw/.ramfs
> 
> Now this means that your approach is inconsistent with the use of 
> standard security tools within the same distribution. I'd like to ask 
> you to EITHER reconsider this strange new policy of putting hidden files 
> under /lib OR provide and maintain a patched version of chrootkit in the 
> distribution . Please, understand that I _don't_ want to recompile 
> chkrootkit, and also don't want to write a wrapper around it to supress 
> these messages, and I suspect that I'm not alone with this desire.

Sure thing.  chkrootkit will have to stop annoying people about this stuff
under /lib/init/rw.  It is already annoying people about other dotfiles and
the threads about it on d-devel were quite clear that the dotfiles will
stay (I don't appreciate these dot-files either, but...).

This bug is a "wontfix" on the sysvinit side for the time being, and even if
we do change it later on for some other reason, chkrootkit would still annoy
people over the other dotfiles from other packages.  Thus, I am reassigning
this bug to chkrootkit.

-- 
  "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

Message #84 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Chris Knadle <Chris.Knadle@coredump.us>

To: 403863@bugs.debian.org

Subject: Bug#403863: Bug has not been reassigned

Date: Wed, 9 May 2007 04:47:19 -0400

Please note:

   This bug has not yet been reassigned to chkrootkit due to the email address 
that was used to reassign the bug.  That needs to go to the email address 
control@bugs.debian.org.  This is explained in:

   http://www.debian.org/Bugs/server-control

   -- Chris

-- 

Chris Knadle
Chris.Knadle@coredump.us

Message #89 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Chris Knadle <Chris.Knadle@coredump.us>

To: 403863@bugs.debian.org

Subject: Bug #403836 merged with #406493

Date: Wed, 9 May 2007 13:24:45 -0400

This post is just for explanation.

Last post was incorrect, as the log in the bug thread shows that the bug was 
reassigned -- my error.
I got confused because I didn't see #403863 anywhere in the list of bugs for 
chkrootkit, and that's because it was merged with #406493.

Appologies for the confusion -- I'm still learning the BTS.

  -- Chris

-- 

Chris Knadle
Chris.Knadle@coredump.us

Message #94 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Sven Wasmer <svenfqab@ww.tu-berlin.de>

To: 403863@bugs.debian.org

Subject: initscripts: Stray file /lib/init/rw/.ramfs not in package list

Date: Wed, 22 Aug 2007 16:14:07 +0200

"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

Message #99 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Keith Edmunds <kae@midnighthax.com>

To: 403863@bugs.debian.org

Subject: initscripts: Stray file /lib/init/rw/.ramfs not in package list

Date: Mon, 27 Aug 2007 09:07:25 +0100

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.

Message #104 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Burkhard <reisswolf_nospam@otzenpunkrock.de>

To: 403863@bugs.debian.org

Subject: chkrootkit and false positive dot-files

Date: Wed, 16 Jan 2008 08:55:49 +0100

Wouldn't it be possible to patch chkrootkit not to ignore certain
hidden files/dirs in every case, but only if they are empty?

I don't see how an empty dot-file could be a useful part of a rootkit,
and neither an empty directory or one that contains nothing more than
other empty files.

Message #109 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Kyle Gordon <kyle@lodge.glasgownet.com>

To: 403863@bugs.debian.org

Subject: initscripts: Stray file /lib/init/rw/.ramfs not in package list

Date: Mon, 3 Mar 2008 09:46:45 +0000

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

Message #114 received at 403863@bugs.debian.org (full text, mbox, reply):

From: "Sam Kuper" <sam.kuper@uclmail.net>

To: 403863@bugs.debian.org

Subject: initscripts: Stray file /lib/init/rw/.ramfs not in package list

Date: Thu, 21 Aug 2008 03:43:35 +0100

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Message #119 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Kenny <kenny@romhat.net>

To: 403863@bugs.debian.org

Cc: Burkhard <reisswolf_nospam@otzenpunkrock.de>

Subject: Re: chkrootkit and false positive dot-files

Date: Sun, 25 Jan 2009 12:57:40 -0800

I am clearly late to the party, but this issue is still unresolved in
Debian stable (presently etch).  More than two years in the waiting.
Ouch.

> I don't see how an empty dot-file could be a useful part of a rootkit,
> and neither an empty directory or one that contains nothing more than
> other empty files.

An empty file can store a wealth of information in the filename,
timestamp, mode bits, attributes (chattr/lsattr), acl (setfacl,
getfacl), and so on.  Verifying that these dot-files are harmless is far
from trivial.

The same could be said about any number of other files, but these in
particular are encouraging people to ignore false positives or add
dangerous excludes to their security systems.  Both of which are likely
to result in missed compromises.  That's not good for any of us.

What is using this file, anyway?  My google codesearch skills are
apparently lacking because aside from /etc/init.d/mountkernfs.sh
touching /lib/init/rw/.ramfs, I don't see anything that stats .ramfs.
Can anyone point me to an example of code that will need to be altered
before we can safely remove this dot-file?

Thanks.
-- 
Kenny
-+---+++-++-++++--+------+-+-++--++--+-+-++--+++-++----+-++-+++---+----+--+----+

Message #124 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: Kenny <kenny@romhat.net>, 403863@bugs.debian.org

Cc: Burkhard <reisswolf_nospam@otzenpunkrock.de>

Subject: Re: [Pkg-sysvinit-devel] Bug#403863: chkrootkit and false positive dot-files

Date: Sun, 25 Jan 2009 22:54:39 +0100

[Kenny]
> I am clearly late to the party, but this issue is still unresolved
> in Debian stable (presently etch).  More than two years in the
> waiting.  Ouch.

One can only wonder why the rootkit detectors still believe this file
is dangerous after more than two years, yes.

> What is using this file, anyway?

The file is created to make sure programs and scripts starting very
early in the boot can know if it is possible and safe to write to
/lib/init/rw/.  Not much is using it yet, but I believe that area
might be key to solving the problems associated with the event based
kernel very early in the boot.

Happy hacking,
-- 
Petter Reinholdtsen

Message #129 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Petter Reinholdtsen <pere@hungry.com>, 403863@bugs.debian.org

Cc: Kenny <kenny@romhat.net>, Burkhard <reisswolf_nospam@otzenpunkrock.de>

Subject: Re: [Pkg-sysvinit-devel] Bug#403863: Bug#403863: chkrootkit and false positive dot-files

Date: Fri, 30 Jan 2009 13:46:48 -0200

On Sun, 25 Jan 2009, Petter Reinholdtsen wrote:
> The file is created to make sure programs and scripts starting very
> early in the boot can know if it is possible and safe to write to
> /lib/init/rw/.  Not much is using it yet, but I believe that area
> might be key to solving the problems associated with the event based
> kernel very early in the boot.

Err, how can it NOT be safe to write there?  And you get immediate feedback
if the system is completely and utterly broken and the write fails,
anyway...

What would be an example of expected use of that marker?  I don't get it,
either.

-- 
  "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

Message #134 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: 403863@bugs.debian.org

Cc: Kenny <kenny@romhat.net>, Burkhard <reisswolf_nospam@otzenpunkrock.de>

Subject: Re: Bug#403863: Bug#403863: chkrootkit and false positive dot-files

Date: Fri, 30 Jan 2009 16:57:58 +0100

[Henrique de Moraes Holschuh]
> Err, how can it NOT be safe to write there?

If something try to write there before /etc/rcS.d/S02mountkernfs.sh
has executed, it will not be possible to write to /lib/init/rw/.

> What would be an example of expected use of that marker?  I don't
> get it, either.

Here is an example:

  if [ -f /lib/init/rw/.ramfs ] ; 
     do_stuff_needing_initrw
  else
     echo "Unable to do stuff, because /lib/init/rw/ is not yet writable"
  fi

Kernel event handlers called from udev (when udev is started in the
initrd) could find it useful to know if /lib/init/rw/ is writable or
not. :)

Happy hacking,
-- 
Petter Reinholdtsen

Message #139 received at 403863@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Petter Reinholdtsen <pere@hungry.com>, 403863@bugs.debian.org

Cc: Burkhard <reisswolf_nospam@otzenpunkrock.de>, Kenny <kenny@romhat.net>

Subject: Re: [Pkg-sysvinit-devel] Bug#403863: Bug#403863: chkrootkit and false positive dot-files

Date: Sat, 31 Jan 2009 11:32:46 -0200

On Fri, 30 Jan 2009, Petter Reinholdtsen wrote:
> [Henrique de Moraes Holschuh]
> > Err, how can it NOT be safe to write there?
> 
> If something try to write there before /etc/rcS.d/S02mountkernfs.sh
> has executed, it will not be possible to write to /lib/init/rw/.

There shouldn't EXIST a non-writeable /lib/init/rw.  But since POSIX
is broken and the only way to have that would be to create the
mountpoint on-the-fly (which we cannot do, / would be RO at that
point)...

> > What would be an example of expected use of that marker?  I don't
> > get it, either.
> 
> Here is an example:
> 
>   if [ -f /lib/init/rw/.ramfs ] ; 
>      do_stuff_needing_initrw
>   else
>      echo "Unable to do stuff, because /lib/init/rw/ is not yet writable"
>   fi

Is there a reason for this?  Do we have any users?  This would do just
as well:

do_stuff_needing_initrw || {
	echo "Failed to do stuff, maybe /lib/init/rw/ is " \
	     "not writeable?"
	exit 1
}

Anyway, since we now have /etc/init.d/.depend* and it is clear we'll
have more and more .crap in system directories from now on, I have
decided to give it up as a waste of effort.

> Kernel event handlers called from udev (when udev is started in the
> initrd) could find it useful to know if /lib/init/rw/ is writable or
> not. :)

This is why I think the whole initrd concept is broken, people do
things halfway instead of accepting the entire broad range of pain
they deserve for putting so much crap on the initrd.

After all, every time you have anything added to the initrd, it is
something else that will not get updated when it should.  It is
getting bad do the point that I am seriously considering regenerating
the initrd on shutdown.

If we need init/rw support in the initrd, it should be done right.  It
should create the initrd init/rw, and when it is finished and ready to
pivot-root, it should move it to its new place on top of the new /.
Yes, it is complex and a hassle, but it can be done.

But if you think about exactly WHAT /lib/init/rw is supposed to be
in the first place, it makes a lot of sense to create it as early as
possible, and that would be the initrd in systems that don't have the
luck of being initrd-less.

-- 
  "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

Message #146 received at 403863-close@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@debian.org>

To: 403863-close@bugs.debian.org

Subject: Bug#403863: fixed in sysvinit 2.88dsf-23

Date: Sat, 21 Apr 2012 12:03:49 +0000

Source: sysvinit
Source-Version: 2.88dsf-23

We believe that the bug you reported is fixed in the latest version of
sysvinit, which is due to be installed in the Debian FTP archive:

bootlogd_2.88dsf-23_amd64.deb
  to main/s/sysvinit/bootlogd_2.88dsf-23_amd64.deb
initscripts_2.88dsf-23_amd64.deb
  to main/s/sysvinit/initscripts_2.88dsf-23_amd64.deb
sysv-rc_2.88dsf-23_all.deb
  to main/s/sysvinit/sysv-rc_2.88dsf-23_all.deb
sysvinit-utils_2.88dsf-23_amd64.deb
  to main/s/sysvinit/sysvinit-utils_2.88dsf-23_amd64.deb
sysvinit_2.88dsf-23.debian.tar.gz
  to main/s/sysvinit/sysvinit_2.88dsf-23.debian.tar.gz
sysvinit_2.88dsf-23.dsc
  to main/s/sysvinit/sysvinit_2.88dsf-23.dsc
sysvinit_2.88dsf-23_amd64.deb
  to main/s/sysvinit/sysvinit_2.88dsf-23_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 403863@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Roger Leigh <rleigh@debian.org> (supplier of updated sysvinit package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Sat, 21 Apr 2012 12:11:45 +0100
Source: sysvinit
Binary: sysvinit sysvinit-utils sysv-rc initscripts bootlogd
Architecture: source amd64 all
Version: 2.88dsf-23
Distribution: experimental
Urgency: low
Maintainer: Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>
Changed-By: Roger Leigh <rleigh@debian.org>
Description: 
 bootlogd   - daemon to log boot messages
 initscripts - scripts for initializing and shutting down the system
 sysv-rc    - System-V-like runlevel change mechanism
 sysvinit   - System-V-like init utilities
 sysvinit-utils - System-V-like utilities
Closes: 55707 232569 385172 403863 438895 518249 539261 540448 543793 545401 545438 550425 558000 562500 567539 585540 587923 596284 596479 596480 596481 596482 596483 614895 623051 634146 636054 652625 659480 659490 660824 664816 665995 666871 667745 668312
Changes: 
 sysvinit (2.88dsf-23) experimental; urgency=low
 .
   [ Roger Leigh ]
   * Acknowledge NMU for translation updates.  Thanks to Christian
     Perrier.
   * debian/control:
     - Upgrade to Standards-Version 3.9.3.
     - Build-Depend on debhelper v9.
     - Correct Vcs-Git URL.
   * debian/rules:
     - Use DEB_HOST_ARCH_OS = hurd rather than
       DEB_HOST_ARCH = hurd-i386.   Thanks to Pino Toscano.
   * debian/patches:
     - 11_lfs_cflags.patch: Add patch for enabling large file support,
       needed on GNU/Hurd, but useful for all platforms.
     - 73_lfs_cflags.patch: Add patch for enabling large file support
       in startpar.
   * initscripts:
     - Moved RAM* settings from /etc/default/rcS to /etc/default/tmpfs.
       This ensures that the settings are equivalent for upgrades and
       new installations, but will require manual configuration of the
       settings for upgrades (no migration from /etc/default/rcS to
       /etc/default/tmpfs will take place, due to tmpfs being a
       conffile).  tmpf(5) manual page added to document all aspects
       of tmpfs configuration, including the existing documentation in
       rcS(5).
     - Drop the use of .ramfs dotfiles in /run and /run/lock.  These
       were a legacy of /lib/init/rw and were not actually used by
       anything.  Closes: #403863.
     - Drop /etc/init.d/mountoverflowtmp.  This has been merged into
       the general tmpfs on /tmp handling functions.  This means the
       generic RAMTMP configuration is used for the overflowtmp.
       Closes: #567539.
     - It is now possible to configure a tmpfs mount size limit as a
       percentage of the total VM size (%VM) as well as a percentage
       of the RAM size (%).  This is computed by tmpfs.sh and the
       tmpfs mounts are remounted with the updated size limit after
       swap becomes available.
     - An fstab entry for /tmp overrides RAMTMP.  Document tmpfs
       override and tmpfs defaults in tmpfs(5), also undeprecating the
       tmpfs settings.  Closes: #585540, #665995.
     - An fstab entry for /run/lock or /run/shm overrides RAMLOCK and
       RAMSHM.
     - bootclean cleans /tmp, /run and /run/lock before any filesystems
       are mounted as well as after local and network mounts.  This
       permits cleaning of directories which would otherwise be hidden
       by mountpoints later in the boot process.
       Closes: #55707, #558000, #666871.  Additionally clean up
       /lib/init/rw in case any files were hidden by the (now removed)
       tmpfs mount at this location.  Closes: #652625.
     - Removed last trace of the long-removed EDITMOTD from the
       postinst.  Closes: #438895.
     - Removed documentation of #346342 in rcS(5).  This is no longer
       an issue now tzdata keeps a copy of the data on the rootfs.
       Closes: #385172.
     - Correct description of TMPTIME in rcS(5).  Thanks to Alan J.
       Greenberger.  Closes: #562500.
     - urandom: Applied a series of patches from John Denker to
       improve the integrity of random number generation.  Many thanks.
       Closes: #596479, #596480, #596481, #596482, #596483.
   * sysv-rc:
     - Remove old upgrade logic from maintainer scripts not required
       for wheezy.
     - Migrate users of obsolete static boot ordering to dynamic boot
       ordering.
     - Remove use of /etc/init.d/.legacy-bootordering.  Closes: #668312.
     - Improve help text of debconf message when it is not possible to
       automatically enable dynamic boot ordering.  Provide explicit
       instructions for how to purge obsolete init scripts.
       Closes: #550425.
     - etc/init.d/rc: Ensure linprocfs is mounted on kFreeBSD.  Thanks
       to Robert Millan.  Closes: #659480.
     - Drop undocumented CONCURRENCY setting from /etc/init.d/rc.
       Closes: #518249, #540448, #539261.  Note that this still contains
       internal fallbacks to support non-insserv booting, which may be
       removed at a later date.
     - invoke-rc.d:
       + Minor manual page corrections.  Thanks to Anthony Fiumara.
         Closes: #664816.
       + Remove mention of the "dpkg Programmers' Manual" and replace
         with references to Debian Policy.  Closes: #543793.
     - update-rc.d:
       + Correctly warn about non-LSB standard runlevels.  Thanks to
         Chris Hiestand for this patch.  Closes: #614895.
       + Remove obsolete documentation of
         /var/lib/sysv-rc/legacy-bootsequence.  Thanks to Thomas Hood.
         Closes: #623051.
   * sysvinit:
     - Minor corrections for halt(8) manual page.  Thanks to
       Christoph Anton Mitterer.  Closes: #587923.
     - Installation with debootstrap --variant=fakechroot now works, due
       to only migrating the old control channel when it is still
       present.  Thanks to Michael Gilbert.  Closes: #596284.
   * sysvinit-utils:
     - Recommend bootlogd.  Closes: #659490.  This means that booklogd
       will be installed by default, but will be removable.
       Closes: #232569.
     - Correct documentation of the startpar -i option.  Closes: #545438.
     - Correct startpar(8) SEE ALSO section.  Closes: #634146.
     - Correct wording in service(8).  Thanks to Joey Hess and Regid
       Ichira.  Closes: #545401, #667745.
 .
   [ Steve Langasek ]
   * debian/service/service: fix upstart compatibility to not try to use the
     upstart commands when init isn't upstart.  Closes: #636054.
   * debian/rules: pass CFLAGS when building startpar.
   * Fix startpar to not run init scripts that have matching upstart jobs,
     instead waiting for a signal from upstart.  Closes: #660824.
       to Robert Millan.  (Closes: #659480)
   * sysvinit:
     - Don't restart or perform initctl migration if systemd is
       running.
Checksums-Sha1: 
 bc1ce99e8e897bd0c09caa53a6bee6b5ad99a6a4 2333 sysvinit_2.88dsf-23.dsc
 9c2501aee21b742339e08a1bb4f92abd6d666cbc 198218 sysvinit_2.88dsf-23.debian.tar.gz
 e5610d9550f696b538297e6d5cb76710578b25eb 129982 sysvinit_2.88dsf-23_amd64.deb
 8ccbeb22e36f6be85e92cc69db2b7d16d3ee48c1 94998 sysvinit-utils_2.88dsf-23_amd64.deb
 68fd3ee6ccea7bc77440b5ed3ec18e5a9e3259c5 74006 sysv-rc_2.88dsf-23_all.deb
 691f64ebd720902076b313d299e0f44f37a260d8 85272 initscripts_2.88dsf-23_amd64.deb
 8b74707590af2e06e45eac57ac867eb91a51dd54 51100 bootlogd_2.88dsf-23_amd64.deb
Checksums-Sha256: 
 22389c9a4e1c9117a57669c143f9f6208fa3dbe684e898b1eecf7a4fad24792b 2333 sysvinit_2.88dsf-23.dsc
 19a631f10b37266365ed017073331c30a58cab9e0d654cc04e4b39dbb22ee8be 198218 sysvinit_2.88dsf-23.debian.tar.gz
 f6eb82ff03cca907c7f93690402b0e79b10d573eb30bcb5d78248f6debd34e4f 129982 sysvinit_2.88dsf-23_amd64.deb
 e239b598ded96eade6150733b185bc7ba62f23af661dba52900026eec8dbd6b8 94998 sysvinit-utils_2.88dsf-23_amd64.deb
 7ae267f015c5d86d478903410557c6fb9ab7cda7b2550e309ee964db3cad52c0 74006 sysv-rc_2.88dsf-23_all.deb
 e078c31ffa9b5c340934ea482e0fa83fbf0a896899349d0fbbf90cfdd5cfafd1 85272 initscripts_2.88dsf-23_amd64.deb
 de9638eeaf51ebcdc9b125dcb3d2a05788207db6bb87eb817a67d75eb28b2a4d 51100 bootlogd_2.88dsf-23_amd64.deb
Files: 
 aff54f9648762cdd27ad03953114ab55 2333 admin required sysvinit_2.88dsf-23.dsc
 73382e2cc02513aa75dd970e903c0449 198218 admin required sysvinit_2.88dsf-23.debian.tar.gz
 aa83f92a867553ef07a037d1d6bcfc36 129982 admin required sysvinit_2.88dsf-23_amd64.deb
 430350412b6147dcb2f55b91f57e63a0 94998 admin required sysvinit-utils_2.88dsf-23_amd64.deb
 d8594c369ef0512c9b4923e5cd850684 74006 admin required sysv-rc_2.88dsf-23_all.deb
 9f887829de6e3d8ec42a7623c0d316e2 85272 admin required initscripts_2.88dsf-23_amd64.deb
 9a58745baa4dc323748af477184eb89f 51100 admin optional bootlogd_2.88dsf-23_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJPkp4iAAoJEOJSSsUKn1xZN3kQAIO3o9ZgT4W4niORSj9vIoZk
m+pSKb1Q9aP0KOPpJeRIFIyeVFSxHNjBeQg0VMerG8jSU0N5LZHa2hEZg+Oji4VI
pbX7kk2a46iH3VJvkGzGSWc7M83n5ymQ9pUT2gz8YBW0vPsOrcZapLLO8nspczFe
VI1iw5tB95/sl8MfQ5oKcOEsZYXz58MRpPfuXeMFi+/kXfQ+OJo95UEjYJH6Jj6T
YxXKiKdVRs49iM/9XlVIUwd8mLfc129DI5kVgXlNokxlqFd5WE9CBeWRckjsWwFF
ntxJSnnN7iwWLmBcZdCuLdiyG+LCu3Hxq6wzp9qL04rpaW3AMRUHyTElqp4U7d8X
AkDtmN18AEvaNrAkpwVLIQrJ3FIblaXDZ5i0Mvh0WB//onuLlQG+hTtRA1a9oJGJ
BeHgDTfXPYTOlcibn4RUNVh/qKLXUS+h+gjHs9K4+W6G5MfLaMnaw6Lcnohdxm+l
02a5il+x+oxAl6BKS9O1qlyNvU71TEUU0OGkiDQruXM0qi63P1dphV1MNhve1w8j
yndjZ7pgHaC/lqzEgkR5t5XPG+WKHNgr34usKg4CT3k35DqIIdg5ZY+oPHI6lRvA
uZIj9FzL95oeuh6TnknbMRZR/gZgMhp2vUQOsFI9ScH6zNCfuaMcRl77R0sazgxP
0iDzU8ik31qzCebdAk5r
=RV6U
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.