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: <alpine.DEB.2.00.0909221139570.12001@makko.or.mcafeemobile.com>
Date:	Tue, 22 Sep 2009 16:43:17 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Jamie Lokier <jamie@...reable.org>
cc:	Eric Paris <eparis@...hat.com>,
	Andreas Gruenbacher <agruen@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Evgeniy Polyakov <zbr@...emap.net>,
	David Miller <davem@...emloft.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org, netdev@...r.kernel.org,
	viro@...iv.linux.org.uk, alan@...ux.intel.com, hch@...radead.org
Subject: Re: fanotify as syscalls

On Tue, 22 Sep 2009, Jamie Lokier wrote:

> Eric Paris wrote:
> > That's not the fatal flaw.  The fatal flaw is that I am not going to
> > write 90% of a rootkit and make it easy to use.
> 
> I hate to point out the obvious, but fanotify's ability to intercept
> every file access and rewrite the file before the access proceeds is
> also 90% of a rootkit...

Obvious, but worth noticing.
Indeed, the syscall table has been RO to make it harder for RKs to 
exploit it, not to make it impossible. RO syscall table makes perfect 
sense.
But, once you are root, with very few lines of code, you can find, 
prot-fix the page, and patch the table.



> But fortunately both fanotify and syscall rewriting require root in
> the first place.                          ^^^^^^^^^

Again, maybe I wasn't clear about how this would work, but the syscall 
table would continue to remain RO ;)
And as I said before, if we want to bring the cost of the interception for 
non-users pretty close to zero (a few NOPs to run onto), we could even 
adopt an alternative-like patching triggered by a kernel boot option.



- Davide


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ