linux-kernel - Re: Providing an ELF flag for disabling LD

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20071213165245.6132529f@the-village.bc.nu>
Date:	Thu, 13 Dec 2007 16:52:45 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Martin Pitt <martin.pitt@...ntu.com>
Cc:	linux-kernel@...r.kernel.org, Ben Collins <ben.collins@...ntu.com>
Subject: Re: Providing an ELF flag for disabling LD_PRELOAD/ptrace()

O> one thing that has bothered me for a long time already is the
> complete lack of a security boundary between processes of the same
> user. Things like LD_PRELOAD and ptrace() (IOW, gdb) are enabled by
> default for all users, and especially for developers this is a good
> thing.

This is the normal Unix model.

> What I want is the behaviour of suid/sgid executables (which do
> something like an atomic prctl(PR_SET_DUMPABLE, 0) to disable vectors
> like ptrace(), LD_PRELOAD, etc. However, making binaries setugid just
> for that is less than ideal, since it requires a lot of code patching
> (to reset the group) and packaging changes (to maintain the
> sgid setting), as well as confusing security scanners, etc.

This is an SELinux problem. In fact this kind of compartmentalisation is
exactly what SELinux is designed to provide.

> So I wonder whether we can define a flag in the ELF header which
> triggers the same behaviour? Can we define an e_flags bit for that?

If it were just ptrace it would be trivial, but its naiive to think that
is the case. Constraining things while not entirely compartmentalising is
a good thing, and policykit is the right path, but the security
components that are needed seem to already exist in SELinux and little ELF
binary header hacks don't do the job properly.

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