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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ