http://bugzilla.spamassassin.org/show_bug.cgi?id=3097
------- Additional Comments From [EMAIL PROTECTED] 2004-04-14 12:17 ------- (Good to hear that Theo's already done the RUID=0 EUID=user thing btw.) But Kelsey makes a good point. 'While I'm personally not that bothered by this much, maintaining a real UID of root through a child process isn't something to do lightly. If there is ever an exploit found in a child and the RUID is root, the box is 0wn3d.' Yes -- good point. we do fork extensively in the scanner, e.g. to run dcc, pyzor etc. We will need to figure this out. Traditionally, the approach is to identify the points where the forking will take place, and rewrite so that after the fork, a RUID=EUID takes place (typically using a helper function that tests if RUID==0 and EUID!=0 and setuids if so). the resulting RUID/EUID map would be: in master process ($$=master): RUID=0 EUID=0 in preforked process ($$=prefork): RUID=0 EUID=0 get username, setuid ($$=prefork): RUID=0 EUID=user scanner ($$=prefork): RUID=0 EUID=user fork to run pyzor ($$=pyzorhelper): RUID=user EUID=user return results ($$=prefork): RUID=0 EUID=user after scanner finishes ($$=prefork): RUID=0 EUID=0 Note that historically privilege-escalation attacks in setuid apps have revolved around finding places where RUID=0, EUID=user, and a fork is done, and replacing what gets forked (or replacing a key env var like PATH, LD_LIBRARY_PATH, LD_PRELOAD or IFS). Note also that on some platforms, some system calls (like getcwd()) will cause a fork. :( 'If the RUID=EUID and EUID!=0 than the attacker has user level access to the server which may lead to other problems if the box is locally exploitable.' That was the previous situation, and is preferable to the above. I think we want to make sure we keep to this situation. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
