linux-kernel - Re: why is the sys_close symbol exported ?

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] [day] [month] [year] [list]

Message-ID: <20161118134943.3eab933f@lxorguk.ukuu.org.uk>
Date:   Fri, 18 Nov 2016 13:49:43 +0000
From:   One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:     jmfriedt <jmfriedt@...to-st.fr>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: why is the sys_close symbol exported ?

On Fri, 18 Nov 2016 09:56:52 +0100
jmfriedt <jmfriedt@...to-st.fr> wrote:

> Following the various rootkit and system call redirection developments, the current
> way of identifying the location of the system call table seems to be brute force scanning 
> the memory for the location of one of the system calls. This is only possible from a module
> if the symbol is exported: I see that only one system call symbol is still exported, that
> is sys_close. Removing this symbol export would hinder one of the ways of finding the 
> systam call table: I have not been able to find the reason for exporting this particular
> symbol (while sys_open for example is not exported). Can anyone justify why that is ?
> 
> Thank you, Jean-Michel
> 

find . -name "*.[ch]" -exec grep -H sys_close {} \;

So currently it is needed by autofs4, binfmt_misc, net/kcm/kcmsock and
those look like legitimate use cases.

It might be worth changing sys_close to just wrap a call to
do_sys_close() which is the existing code. That would make it slightly
harder.

That said anyone doing syscall table scanning that would can do it at
least two other pretty reliable ways by working form the system call
entry point, which is trivially discoverable.

It's one reason I'd really like to see kvm/qemu provide 'read only until
the virtual machine exits' memory range so that you can irrevocably
protect page ranges (like the syscalls and much of the kernel code)
within a VM.

Alan