Quibble re faq errors

[David Collier-Brown]

Andrew Tridgell wrote:
> 
> I recently went through the FAQ replies in samba-bugs and found some
> errors. I am explaining them here as they indicate that samba-team
> members don't understand some issues.
> 
>     Samba does NOT impose security constraints on your Unix sytsem. If you use
>     share mode security you are taking a risk. Share mode security is not
>     secure. If security is a concern then PLEASE use in your smb.conf file
>     "security = user". This ensures that EVERY SMB client connection is
>     authenticated as the user who is logging in. All Unix permissions are
>     fully and completely preserved by Samba.
> 
> this is quite incorrect (the bit about share level security being
> insecure). share level security is just as secure in samba as user
> level security is. The difference is the administrative convenience of
> the two and what authentication order the client will use, not how
> secure they are.

	You're both right (:-))

	I think the warning was rather misleading: as Andrew says,
	the thing which changes is the thing which is authenticated
	(a shared account, used to give a password to the share), 
	not the strength of the authentication.

	Alas, the concept of a shared account is problematic, 
	and requires analysis if you're trying to use the Unix
	security model.  This is because it runs up against two of
	the security-related design principles.  

	To paraphrase Ritchie, ``Unix allows you to do all sort of 
	dumb things, so it can also allow you to brilliant things'' 
	and ``You can cause a problem, but we know who you are''.  
	The two work together to put a logical bound on denial of 
	service attacks.

	A shared account blows the logic above and allows anonymous 
	D of S attacks.  To avoid them, you have to swap from the
	pleasant ``anything not prohibited is permitted'' regime
	of Unix to the paranoid's one of ``everything not expressly
	permitted is forbidden''.  

	This is a the kind of thing you put up with on a firewall
	because they can't have credible authentication in TCP/IPv4
	and UDP/IPv<anything>

	Most people will just say to hell with it and allow the
	D of S attacks because it's too much brainwork to figure
	the implications and block them.  Some fools will flip the
	security policy to fully paranoid, and blame Samba security
	when they're challenged.
	

	We need a way to say that security = share is old, requires
	a dummy account per share, and shared accounts are undesirable
	in Unix. The latter **can** raise security concerns. Use
	security = user to match the implicit Unix security model.
	Then footnote the reason.
	
	Exactly the same thing is true of force user, by the way!


	Final comment: Samba security is really rather good, and
	is more stringent than Unix exactly where it is required:
	where Samba adds access-over-the-net.  Much better than NFS.
	Its only in a few areas where it falls down, due to the
	need for backwards compatibility.

--dave (who recently committed the same sin: oversimplification) c-b	
-- 
David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | davecb at hobbes.ss.org, canada.sun.com
N2M 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb