I have a security-sensitive customer...

Andrew Bartlett abartlet at samba.org
Thu May 19 13:57:18 GMT 2005


On Thu, 2005-05-19 at 09:39 -0400, David Collier-Brown wrote:
> Andrew Bartlett wrote:
> >  What changed was where it spends the idle cycles, but it
> > is no more/less secure.
> 
> 	See below...
> > 
> > Yes, we are screwed on a buffer overflow either way.
> 
> 	Actually I'd argue that a buffer overflow (or other
> 	oops) induced by the user is way more serious
> 	if it occurs while one is running as root.

No.  See the smbd always has the saved uid of root, so can always (next
instruction) ask the kernel to make them root again.  Samba does this
all the time, and I'm pretty sure that's what the various exploits for
Samba over time have done.

> 	This is basically what the customer is stressed
> 	about: privelege escalation attacks.
> 
> 	Now this is no more or less secure than before,
> 	as you noted above, it's just more visible to 
> 	the user, which caused him to whack me over 
> 	the head with the privilege escalation question (:-)) 
> 
> 
> > For the times when we are actually accessing files, we 'become' the
> > connecting user.  This causes the kernel to enforce file access control
> > on that basis, while still allowing us to switch back to root (and
> > subsequently other users) for other operations.
> 
> 	Yes, they understand that, they know it's normal.
> 	
> >> Have we an answer to their concerns? In particular, are 
> >> there cases where the way we do it is more secure?
> 
> 	Is there an argument we can legitimately make
> 	that smbd is consciously considered a security-
> 	critical program,and that we **downgrade**
> 	privilege whenever accessing anything which is
> 	under access control? 

All that has changed is where we spend the idle loop.  Previously we
would spend the idle loop in the context of the last user, hoping we
would be that user again.  Now we return to root sooner.

You could make that argument if it makes the customer happy.  Like a
kernel, Samba itself is a trusted process (see the discussion about
selinux on how it just is not possible to make samba otherwise).

> 	The latter clause is trivially true, we really 
> 	do do that (:-)), and I'd suggest that it is
> 	easier to audit that code than it is to audit
> 	all the intentional escalations in 2.x.

Perhaps the fact that 2.2 has known security holes will help them decide
that real exploits trump theoretical ideas?

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20050519/0e4896d7/attachment.bin


More information about the samba-technical mailing list