linux-kernel - Re: [malware-list] scanner interface proposal was: [TALPA] Intro linux interface for for access scanning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1219260367.3389.125.camel@localhost.localdomain>
Date:	Wed, 20 Aug 2008 15:26:07 -0400
From:	Eric Paris <eparis@...hat.com>
To:	david@...g.hm
Cc:	Jan Harkes <jaharkes@...cmu.edu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, tvrtko.ursulin@...hos.com,
	Theodore Tso <tytso@....edu>, davecb@....COM,
	Adrian Bunk <bunk@...nel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	malware-list@...ts.printk.net,
	Casey Schaufler <casey@...aufler-ca.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [malware-list] scanner interface proposal was: [TALPA] Intro
	linux interface for  for access scanning

On Wed, 2008-08-20 at 10:33 -0700, david@...g.hm wrote:

> if the system package manager says the syslogd binary doesn't match the 
> checksum that it has recorded should it be prevented from running? (a 
> strict policy would say no, but the sysadmin may have recompiled that one 
> binary and just wants a warning to be logged somewhere, not preventing the 
> process from running)

My belief is that if you choose to run a file scanner and that file
scanner gets the answer wrong you need to look at the file scanner.
There shouldn't be arbitrary overrides.  If you don't accept the results
of the scanner what's the point?  Tell you package manager scanner that
you changed it.

> without the kernel support to clear the flags when the file is dirtied how 
> can these programs trust the xattr flags that say they scanned the file 
> before?

I don't understand what you mean about trust.  This is an argument for
kernel support now?  What is it that you say needs and what doesn't need
it?  Can you explain exactly what your perfect solution from top down?

> I'm not saying that xattr is the only way to store the info, it just seems 
> like a convienient place to store them without having to create a 
> completely new API or changing anything in on-disk formats.

And I saying we don't actually need any of this and if it is actually
needed by someone in the real world they can easily build their own
solution on top of my generic interface.  I'm not making the assertion
it is race free and don't think it is possible without making every
sequential (hahahaha.)  But I claim in the face of normal operation it's
fine.  My interface, as proposed, is very generic.  Much more so than
what I think you are trying to describe.  I couldn't make mine more
minimal or broad.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/