Re: PaX options required by clamav

Am 24.04.2013 00:25, schrieb Javier Juan Martínez Cabezón:
> After almost being crazy because of this question I finished with my
> Dazuko problems related, CONFIG_PAX_USERCOPY and
> CONFIG_PAX_MEMORY_UDEREF must be disabled in the kernel config.
> 
> I think this point should be introduced in the handbook in DAZ module,
> until this will be truth, I expect this could serve as a substitution if
> someone search info related about this.
> 
> Thanks a lot Amon for your points I got disoriented at all before this.

Thank you for finding this out and clarifying!

> PD: I think that PaX Softmode should be put in the handbook too, at
> least a point that it does only permit anyone to set/read PaX Flags
> until my Known without disabling any functionality (one softmode
> approach could be for example setting all flags to permxs, but others as
> uderef, usercopy etc etc got free to kill whatever they want)

Right, softmode is a difficult thing. We could do this, similar to CAP
behaviour. However, if you switch it off afterwards, the processes keep
running with more rights that they should have, leaving you with a false
sense of security. So we would have to go through the process list and
reset the flags according to the executed program. Possible, but
annoying with potential to kill half finished jobs.

> Another question useful to the handbook (I will not finish until our
> beloved "handbook" would need 300 kg of paper to print....at least) is
> some tips about configuration of su, removing for example pam_rootok
> (incompatible with the following configuration), removing CHANGE_OWNER
> against USER right and all AUTH caps and grant only CHANGE_AUTHED_OWNER
> of course with UM and permiting AUTH to suid all authed uid and GID. I
> think this is the most secure approach and because of this a serious
> candidate to the handbook.
> 
> The same with login.
> 
> ssh is a bit trickier, with the permanently_set[uid] from the damned
> uidswap.c, and their demonical setresuid() calls when I got one nice
> configuration with proper dropping to 22 (this with CHANGE_OWNER to and
> AUTH cap 22), I will tell (openssh 5.9 is even more trickier.
> 
> Have fun folks (while I still with my nightmare :P )

Thanks once more for all this info. Our handbook could need a lot of
caring attention. So much work to do and so little time. We would need
some volunteer or some funded worker to do all the docs properly - and
continuously over years. So far we have had several volunteers for docs,
but all of them could not go on for various reasons.

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22