linux-kernel - Re: Out of tree module using LSM

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]

Date:	Sat, 1 Dec 2007 08:43:32 +0000
From:	Pavel Machek <pavel@....cz>
To:	tvrtko.ursulin@...hos.com
Cc:	Andi Kleen <andi@...stfloor.org>, ak@...e.de,
	linux-kernel@...r.kernel.org
Subject: Re: Out of tree module using LSM

Hi!

> > Personally I admit I never quite saw the point of intercepting all
> > file accesses for everything. That will just always be slow as often
> > demonstrated on other operating systems and racey and unreliable too.
> > And at least the internal daemons should be already reasonably well
> > protected by standard (or beyond standard, like AA/SELinux etc.)
> > security measures, so e.g. it does not really make sense to intercept
> > all of your /etc file accesses and similar.
> 
> Personally I don't know. I am often surprised when I hear what techniques 
> the bad guys use and what is possible.
> 
> Solution that we currently have is not so slow (btw you are free to try it 
> out). And by working on a proper interface race and reliability issues 
> should be solvable.

Really?

So what you are trying to do is 'application may never read bad
sequence of bits from disk', right?

Now, how do you propose to solve mmap(MAP_SHARED)? The app on the other cpu may
see the bad bits before kernel has chance to see them.

> > It might be better to identify the services (gateway, samba, file
> > server whatever) that are actually dealing with possible infected
> > "external" files and then define some generic interface that would
> > allow you to check those as the data appears.
> > 
> > I would expect such an approach to perform better in the end and be more
> > reliable too.
> > 
> > Note such a interface might well be user space only.
> 
> That is fine for some classes of servers. But for some other and desktop 
> more could be needed. 

Andi's solution seems the only one that has chance to work _reliably_.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/