Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Vuln-Dev
[Top] [All Lists]

Re: Remove all admin->root authorization prompts from OSX

Subject: Re: Remove all admin->root authorization prompts from OSX
Date: Fri, 26 Jan 2007 09:36:11 +0100
Hello,

About sudo in particular.

* You can force for a prompt (5mn by default on Mac OSX,) adding a line
such as the following in /etc/sudoers (using the visudo command):
  Defaults        timestamp_timeout = 0

* By default users do not authenticate on a per-tty basis. You can
enforce it with the following option:
  Defaults        tty_tickets

The last is activated by default on GNU/Linux distro Ubuntu. The reading
of the sudoers manual page is a very interesting.

Regards,

-- 
Baptiste MALGUY - System Engineer                           EASYNET
PGP Fingerprint: 49B0 4F6E 4AA8 B149 B2DF  9267 0F65 6C1C C473 6EC2
www.easynet.com - phone: +33 1 44 54 70 00 - fax: +33 1 44 54 70 01

--

Marvin Simkin wrote:
I respectfully disagree with this proposal and maybe we should discuss it.

Being a member of the admin group is NOT 100% equal to being root. Therefore 
when you switch from admin group to uid=0 you are escalating privileges. A 
trojan that gets control of an admin's session should not be able to escalate 
itself to root without a password prompt, which requires a human to decide 
(rightly or wrongly...) yes I do want to increase the authority of this 
process.

Sure, an admin should be smart enough not to get trojaned, but what if they 
do anyway?

Maybe a cracker could write a trojan that esclates itself using the powers of 
the admin group, but why make it easier for those who don't know how?

The myth that it should be easy for uneducated users to expose their 
computers to harm is one reason why certain other GUI platforms have so many 
security problems.


host:/tmp1 sysmsimkin$ id
uid=505(sysmsimkin) gid=505(sysmsimkin) groups=505(sysmsimkin), 
81(appserveradm), 79(appserverusr), 80(admin)
host:/tmp1 sysmsimkin$ ls -ld /tmp1
drwxr-xr-x   3 501  admin  102 Jun 28  2006 /tmp1
host:/tmp1 sysmsimkin$ mkdir /tmp1/tmp2
mkdir: /tmp1/tmp2: Permission denied
host:/tmp1 sysmsimkin$ /usr/bin/sudo /bin/bash
Password:
host:/tmp1 root# mkdir /tmp1/tmp2
host:/tmp1 root# ls -ld /tmp1/tmp2
drwxr-xr-x   2 root  admin  68 Jan 25 11:20 /tmp1/tmp2
host:/tmp1 root# exit
host:/tmp1 sysmsimkin$ rmdir /tmp1/tmp2
rmdir: /tmp1/tmp2: Permission denied
host:/tmp1 sysmsimkin$ /usr/bin/sudo /bin/bash
host:/tmp1 root# rmdir /tmp1/tmp2
host:/tmp1 root# exit
host:/tmp1 sysmsimkin$ 

More interesting (to me) why wasn't I prompted for a password the second 
time? (Yes I know it was designed that way, I'm asking was that the right 
decision.) Presumably there is a window of vulnerability for a few minutes 
AFTER you have been root during which you could fall victim to a trojan.





Attachment: signature.asc
Description: OpenPGP digital signature

<Prev in Thread] Current Thread [Next in Thread>