[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Common security checks for a base installation - packages reviewed.

On Mon, Dec 30, 2002 at 09:52:36PM +0100, Russell Coker wrote:

> Is there any real point to such a scan?
> If a hostile user can attack the system to change the permissions or contents 
> of a trusted file (anything in {/usr,}/{s,}bin etc) then surely they can 
> change the program that checks the permissions, the libc6, the database of 
> MD5's, or something else to prevent the checks being done properly.

  We're trying to deal with the case where the hostile user has that
 level of access, but doesn't necessarily know the system intimately.
  There's a window of detectability after the system has been compromised,
 and before the attacker spots the checksumming - by which point the admin
 have been notified.

  Most software security systems are prone to failure under a sufficient level
 of breach but that doesn't mean that we shouldn't try to deal with them, or
 catch them.

  After all the checksumming is just one layer in a, hopefully, finegrained

  (My setup involves having a list of MD5's on a cd-rom along with a statically
 compiled md5sums binary.  This is called on a cronjob to do a comparision,
 I know the sums can't be changed - but it's not perfect.  An attack could
 modify the loader  to patch the binary as it's being loaded, or simply remove
 the cronjob - and send fake "everything is OK" messages).

> Why not just run SE Linux or one of the other MAC systems to prevent the files 
> being modified in the first place?

  Another layer of security - even on an SE Linux system I would want to know
 if files have changed.  It may be benign, it could be a legitimate admin
 as modified a file - but relying on _just_ SE Linux et al to protect the 
 system ignores all the past breaches in security due to faulty software,
 or badly deployed security measures.

  More layers == better protection.

> Writing a "no way out" policy for SE Linux that prevents the important files 
> or the security policy from being changed is easy enough to do.

  That could well be the case, but I wouldn't want that to be the only 
 protection - and the paranoid users probably wouldn't want a single point
 of failure either.


Reply to: