Quibble re faq errors
David Collier-Brown
davecb at Canada.Sun.COM
Mon Nov 9 12:53:50 GMT 1998
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
More information about the samba-technical
mailing list