Re: [rfc] change default setuid permissions from 4755 to 4711

On Wednesday 03 August 2005 06:26 am, Tomasz Kłoczko wrote:
> On Tue, 2 Aug 2005, Mike Frysinger wrote:
> > we've been patching the permissions in shadow for a while now from 4755
> > to 4711 ... i dont think anyone here has asked the shadow maintainers, so
> > i'm doing so now :)
> >
> > there's no need to grant read permissions for setuid binaries, so 4711 is
> > just as functional as 4755, while keeping internal binary information
> > (such as function addresses) hidden
>
> Q: do you know what is it SbO (Security by Obscurity) ?
> If you don't go ahead and learn something about this ..

i'm guessing by your condescending tone here that you believe security by 
obscurity has no place anywhere.  i'm pretty familiar with the topic, but i'm 
guessing that unlike you, i believe it has a place in protecting systems by 
restricting information that (1) is not required for the program to run 
normally (2) makes penetration harder (a relative measure of course).  the 
general policy in Gentoo is to set all setuid binaries to 4711 rather than 
4755 rather than picking out certain ones (such as shadow).

> Hint: if for example one of shadow setuid tools will have known security
> bug. How do think .. how many seconds intruder will stop for checkin is
> attacked binary is readable or not ? (before runing exploit) and/or is
> in this case removing read atrubutes will help or not ?

i never said that obscuring the data would protect the binaries.  it will 
simply make it harder for the cracker (depending on the attack vector of 
course) to exploit the vulnerability (whatever it may be).  a readable setuid 
binary can be copied to a local directory or machine for analysis with 
gdb/whatever to figure out the exact parameters needed for a successful 
attack.  which is more likely to be missed by someone reviewing logfiles ?  
one successful attack which benefited from system analysis ahead of time or 
many unsuccessful attacks because the attacker had to systematically tweak 
values until it worked ?

why export this information to all users if restricting it makes no difference 
to the functionality ?  on binary-based distros such as 
Debian/Redhat/SuSe/etc...  this changes nothing since an attacker can simply 
grab the package from somewhere else, but on source based systems such as 
Gentoo/Sorcerer/ROCK/etc... the binaries in use are not available anywhere 
else for analysis.
-mike