linux-admin.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Javier Fernández-Sanguino Peña" <jfs@computer.org>
To: Christian Robottom Reis <kiko@async.com.br>
Cc: linux-admin@vger.kernel.org, debian-security@lists.debian.org
Subject: Re: readdir and checksecurity
Date: Wed, 24 Mar 2004 16:02:37 +0100	[thread overview]
Message-ID: <20040324150237.GA4060@dat.etsit.upm.es> (raw)
In-Reply-To: <20040324135507.GA940@async.com.br>

[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]

On Wed, Mar 24, 2004 at 10:55:08AM -0300, Christian Robottom Reis wrote:
> 
> Hi there,
> 
>     one of our servers (which runs Debian Woody) was recently
> compromised, and had a suckit variant installed. We've gone through the
> reinstall and restore steps, and one of the things I looked at is
> debian's /usr/sbin/checksecurity script, which checks for changes in
> setuid files. 
(...)
> My question is: doesn't this situation sort of invalidate
> checksecurity's setuid check, since setuid files that are in "hidden"
> directories won't show up in the listing?

IMHO any local host intrusion detection system (hids) is screwed once the
system gets compromised. That is:

- you cannot trust it at all (it might have been replaced with other stuff 
that will never alert you)
- you cannot trust its reports (it might be based on false information 
since it can be tricked by the rootkit, just like a local admin might be)

The deeper you put the hids in (that is, kernel space vs. userspace) the 
more you can trust it or expect it to find hidden stuff. But even then
there are always ways around it if can have a rootkit installed and running 
as root [0]

That being said, you could argue that the setuid check is useless but, 
still, it might be able to find some stuff that the intruder left around 
without knowing it (people make mistakes, worms do too). And it still might 
alert you _before_ the rootkit gets installed [1] (in some cases, a system 
reboot is needed in order to get a proper rootkit installed, and the setuid 
check might run before that reboot).

I wouldn't consider checksecurity's suid problem a bug, more like a 
limitation.

Just my 2c.

Regards

Javier


[0] Unless, of course, you use MAC (se-linux, rsbac....) and even then it 
might only make it more difficult not necessarily impossible.
[1] _If_ you send these alerts/reports off-site, otherwise they can be 
manipulated after the intruder got admin priviledges (most rootkits can 
wipe out logfiles, they don't wipe out checksecurity setuid's files just 
because Debian is not yet an specific target of rootkits AFAIK)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

      reply	other threads:[~2004-03-24 15:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-24 13:55 readdir and checksecurity Christian Robottom Reis
2004-03-24 15:02 ` Javier Fernández-Sanguino Peña [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040324150237.GA4060@dat.etsit.upm.es \
    --to=jfs@computer.org \
    --cc=debian-security@lists.debian.org \
    --cc=kiko@async.com.br \
    --cc=linux-admin@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).