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
| ||
|
Message-ID: <1079383086.2544.96.camel@coruscant.weisserth.net> From: tobias at weisserth.de (Tobias Weisserth) Subject: a secure base system Hi Alexander, Am Mo, den 15.03.2004 schrieb Alexander Bartolich um 20:27: > Tobias Weisserth wrote: > > /tmp should always be mounted noexec. Add /home as well with noexec. > > [...] This may be a trade-off, but the result is more security. > > On typical Linux distributions noexec is pointless. > It does not prevent the execution of dynamically linked ELF images. Interesting point. But I guess "noexec" still is useful for running services, trapped inside a chroot and running under an user with almost no privileges, with the chroot residing on such a noexec partition. If the service is exploitable and an attacker gains the privileges of the user running the service he might not be able to leave the chroot and use the circumvention to bypass the noexec option. Or am I wrong here? I really appreciate your explanation. You are of course right that I might not be able to hinder individual users who possess this knowledge with a home directory and a bash login to run or install programs inside their home directory by just mounting it noexec. Maybe limiting access to "readelf" helps, but I doubt that since most binaries are linked to the file you used below... interesting point indeed ;-) > $ readelf -l /bin/bash | grep interpreter > [Requesting program interpreter: /lib/ld-linux.so.2] > > $ /lib/ld-linux.so.2 /bin/bash --version > GNU bash, version 2.05b.0(1)-release (i386-redhat-linux-gnu) > Copyright (C) 2002 Free Software Foundation, Inc. Well, at least the noexec option for /tmp prevents 99% of available ready-to-run exploits and root kits to execute properly, since they were written to run from within /tmp. I guess this takes care of most of the simple "script-kiddies". But you're right. I doesn't really "solve" the problem. But it raises the bar because exploits have to be adapted and luckily not everybody is able to do this. regards, Tobias W. -- *************************************************** ____ _____ | _ \| ____| Tobias Weisserth | | | | _| tobias@...sserth.[de|com|net|org] _| |_| | |___ http://www.weisserth.org (_)____/|_____| Encrypted mail is welcome. Key and fingerprint: http://imprint.weisserth.org ***************************************************
Powered by blists - more mailing lists