| 1 | <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 18. Securing Samba</title><link rel="stylesheet" href="../samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="The Official Samba 3.5.x HOWTO and Reference Guide"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="prev" href="locking.html" title="Chapter 17. File and Record Locking"><link rel="next" href="InterdomainTrusts.html" title="Chapter 19. Interdomain Trust Relationships"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 18. Securing Samba</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="locking.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="InterdomainTrusts.html">Next</a></td></tr></table><hr></div><div class="chapter" title="Chapter 18. Securing Samba"><div class="titlepage"><div><div><h2 class="title"><a name="securing-samba"></a>Chapter 18. Securing Samba</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Andrew</span> <span class="surname">Tridgell</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:tridge@samba.org">tridge@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:jht@samba.org">jht@samba.org</a>></code></p></div></div></div></div><div><p class="pubdate">May 26, 2003</p></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="securing-samba.html#id383406">Introduction</a></span></dt><dt><span class="sect1"><a href="securing-samba.html#id383500">Features and Benefits</a></span></dt><dt><span class="sect1"><a href="securing-samba.html#id383634">Technical Discussion of Protective Measures and Issues</a></span></dt><dd><dl><dt><span class="sect2"><a href="securing-samba.html#id383647">Using Host-Based Protection</a></span></dt><dt><span class="sect2"><a href="securing-samba.html#id383792">User-Based Protection</a></span></dt><dt><span class="sect2"><a href="securing-samba.html#id383849">Using Interface Protection</a></span></dt><dt><span class="sect2"><a href="securing-samba.html#firewallports">Using a Firewall</a></span></dt><dt><span class="sect2"><a href="securing-samba.html#id384176">Using IPC$ Share-Based Denials </a></span></dt><dt><span class="sect2"><a href="securing-samba.html#id384309">NTLMv2 Security</a></span></dt></dl></dd><dt><span class="sect1"><a href="securing-samba.html#id384357">Upgrading Samba</a></span></dt><dt><span class="sect1"><a href="securing-samba.html#id384398">Common Errors</a></span></dt><dd><dl><dt><span class="sect2"><a href="securing-samba.html#id384413">Smbclient Works on Localhost, but the Network Is Dead</a></span></dt><dt><span class="sect2"><a href="securing-samba.html#id384437">Why Can Users Access Other Users' Home Directories?</a></span></dt></dl></dd></dl></div><div class="sect1" title="Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id383406"></a>Introduction</h2></div></div></div><p>
|
|---|
| 2 | <a class="indexterm" name="id383414"></a>
|
|---|
| 3 | <a class="indexterm" name="id383421"></a>
|
|---|
| 4 | <a class="indexterm" name="id383427"></a>
|
|---|
| 5 | <a class="indexterm" name="id383434"></a>
|
|---|
| 6 | <a class="indexterm" name="id383441"></a>
|
|---|
| 7 | <a class="indexterm" name="id383448"></a>
|
|---|
| 8 | <a class="indexterm" name="id383455"></a>
|
|---|
| 9 | The information contained in this chapter applies in general to all Samba installations. Security is
|
|---|
| 10 | everyone's concern in the information technology world. A surprising number of Samba servers are being
|
|---|
| 11 | installed on machines that have direct internet access, thus security is made more critical than it would have been had the
|
|---|
| 12 | server been located behind a firewall and on a private network. Paranoia regarding server security is causing
|
|---|
| 13 | some network administrators to insist on the installation of robust firewalls even on servers that are located
|
|---|
| 14 | inside secured networks. This chapter provides information to assist the administrator who understands
|
|---|
| 15 | how to create the needed barriers and deterents against <span class="quote">“<span class="quote">the enemy</span>”</span>, no matter where [s]he may
|
|---|
| 16 | come from.
|
|---|
| 17 | </p><div class="blockquote"><blockquote class="blockquote"><p>
|
|---|
| 18 | A new apprentice reported for duty to the chief engineer of a boiler house. He said, <span class="quote">“<span class="quote">Here I am,
|
|---|
| 19 | if you will show me the boiler I'll start working on it.</span>”</span> Then engineer replied, <span class="quote">“<span class="quote">You're leaning
|
|---|
| 20 | on it!</span>”</span>
|
|---|
| 21 | </p></blockquote></div><p>
|
|---|
| 22 | Security concerns are just like that. You need to know a little about the subject to appreciate
|
|---|
| 23 | how obvious most of it really is. The challenge for most of us is to discover that first morsel
|
|---|
| 24 | of knowledge with which we may unlock the secrets of the masters.
|
|---|
| 25 | </p></div><div class="sect1" title="Features and Benefits"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id383500"></a>Features and Benefits</h2></div></div></div><p>
|
|---|
| 26 | <a class="indexterm" name="id383508"></a>
|
|---|
| 27 | <a class="indexterm" name="id383514"></a>
|
|---|
| 28 | <a class="indexterm" name="id383521"></a>
|
|---|
| 29 | <a class="indexterm" name="id383528"></a>
|
|---|
| 30 | There are three levels at which security principles must be observed in order to render a site
|
|---|
| 31 | at least moderately secure. They are the perimeter firewall, the configuration of the host
|
|---|
| 32 | server that is running Samba, and Samba itself.
|
|---|
| 33 | </p><p>
|
|---|
| 34 | Samba permits a most flexible approach to network security. As far as possible Samba implements
|
|---|
| 35 | the latest protocols to permit more secure MS Windows file and print operations.
|
|---|
| 36 | </p><p>
|
|---|
| 37 | <a class="indexterm" name="id383545"></a>
|
|---|
| 38 | <a class="indexterm" name="id383552"></a>
|
|---|
| 39 | <a class="indexterm" name="id383559"></a>
|
|---|
| 40 | Samba can be secured from connections that originate from outside the local network. This can be done using
|
|---|
| 41 | <span class="emphasis"><em>host-based protection</em></span>, using Samba's implementation of a technology known as
|
|---|
| 42 | <span class="quote">“<span class="quote">tcpwrappers,</span>”</span> or it may be done be using <span class="emphasis"><em>interface-based exclusion</em></span> so
|
|---|
| 43 | <span class="application">smbd</span> will bind only to specifically permitted interfaces. It is also possible to set specific share- or
|
|---|
| 44 | resource-based exclusions, for example, on the <em class="parameter"><code>[IPC$]</code></em> autoshare. The <em class="parameter"><code>[IPC$]</code></em> share is used for browsing purposes as well as to establish TCP/IP connections.
|
|---|
| 45 | </p><p>
|
|---|
| 46 | <a class="indexterm" name="id383601"></a>
|
|---|
| 47 | <a class="indexterm" name="id383610"></a>
|
|---|
| 48 | <a class="indexterm" name="id383617"></a>
|
|---|
| 49 | Another method by which Samba may be secured is by setting Access Control Entries (ACEs) in an Access
|
|---|
| 50 | Control List (ACL) on the shares themselves. This is discussed in
|
|---|
| 51 | <a class="link" href="AccessControls.html" title="Chapter 16. File, Directory, and Share Access Controls">File, Directory, and Share Access Controls</a>.
|
|---|
| 52 | </p></div><div class="sect1" title="Technical Discussion of Protective Measures and Issues"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id383634"></a>Technical Discussion of Protective Measures and Issues</h2></div></div></div><p>
|
|---|
| 53 | The key challenge of security is that protective measures suffice at best
|
|---|
| 54 | only to close the door on known exploits and breach techniques. Never assume that
|
|---|
| 55 | because you have followed these few measures, the Samba server is now an impenetrable
|
|---|
| 56 | fortress! Given the history of information systems so far, it is only a matter of time
|
|---|
| 57 | before someone will find yet another vulnerability.
|
|---|
| 58 | </p><div class="sect2" title="Using Host-Based Protection"><div class="titlepage"><div><div><h3 class="title"><a name="id383647"></a>Using Host-Based Protection</h3></div></div></div><p>
|
|---|
| 59 | <a class="indexterm" name="id383655"></a>
|
|---|
| 60 | <a class="indexterm" name="id383661"></a>
|
|---|
| 61 | <a class="indexterm" name="id383668"></a>
|
|---|
| 62 | In many installations of Samba, the greatest threat comes from outside
|
|---|
| 63 | your immediate network. By default, Samba accepts connections from
|
|---|
| 64 | any host, which means that if you run an insecure version of Samba on
|
|---|
| 65 | a host that is directly connected to the Internet, you can be
|
|---|
| 66 | especially vulnerable.
|
|---|
| 67 | </p><p>
|
|---|
| 68 | <a class="indexterm" name="id383681"></a>
|
|---|
| 69 | <a class="indexterm" name="id383688"></a>
|
|---|
| 70 | One of the simplest fixes in this case is to use the <a class="link" href="smb.conf.5.html#HOSTSALLOW" target="_top">hosts allow</a> and
|
|---|
| 71 | <a class="link" href="smb.conf.5.html#HOSTSDENY" target="_top">hosts deny</a> options in the Samba <code class="filename">smb.conf</code> configuration file to
|
|---|
| 72 | allow access to your server only from a specific range of hosts. An example might be:
|
|---|
| 73 | </p><table border="0" summary="Simple list" class="simplelist"><tr><td><a class="indexterm" name="id383731"></a><em class="parameter"><code>hosts allow = 127.0.0.1 192.168.2.0/24 192.168.3.0/24</code></em></td></tr><tr><td><a class="indexterm" name="id383743"></a><em class="parameter"><code>hosts deny = 0.0.0.0/0</code></em></td></tr></table><p>
|
|---|
| 74 | </p><p>
|
|---|
| 75 | <a class="indexterm" name="id383757"></a>
|
|---|
| 76 | <a class="indexterm" name="id383764"></a>
|
|---|
| 77 | <a class="indexterm" name="id383771"></a>
|
|---|
| 78 | The above will allow SMB connections only from <code class="constant">localhost</code> (your own
|
|---|
| 79 | computer) and from the two private networks 192.168.2 and 192.168.3. All other
|
|---|
| 80 | connections will be refused as soon as the client sends its first packet. The refusal
|
|---|
| 81 | will be marked as <code class="literal">not listening on called name</code> error.
|
|---|
| 82 | </p></div><div class="sect2" title="User-Based Protection"><div class="titlepage"><div><div><h3 class="title"><a name="id383792"></a>User-Based Protection</h3></div></div></div><p>
|
|---|
| 83 | If you want to restrict access to your server to valid users only, then the following
|
|---|
| 84 | method may be of use. In the <code class="filename">smb.conf</code> <em class="parameter"><code>[global]</code></em> section put:
|
|---|
| 85 | </p><table border="0" summary="Simple list" class="simplelist"><tr><td><a class="indexterm" name="id383818"></a><em class="parameter"><code>valid users = @smbusers, jacko</code></em></td></tr></table><p>
|
|---|
| 86 | </p><p>
|
|---|
| 87 | <a class="indexterm" name="id383832"></a>
|
|---|
| 88 | This restricts all server access either to the user <span class="emphasis"><em>jacko</em></span>
|
|---|
| 89 | or to members of the system group <span class="emphasis"><em>smbusers</em></span>.
|
|---|
| 90 | </p></div><div class="sect2" title="Using Interface Protection"><div class="titlepage"><div><div><h3 class="title"><a name="id383849"></a>Using Interface Protection</h3></div></div></div><p>
|
|---|
| 91 | <a class="indexterm" name="id383857"></a>
|
|---|
| 92 | <a class="indexterm" name="id383864"></a>
|
|---|
| 93 | <a class="indexterm" name="id383871"></a>
|
|---|
| 94 | By default, Samba accepts connections on any network interface that
|
|---|
| 95 | it finds on your system. That means if you have an ISDN line or a PPP
|
|---|
| 96 | connection to the Internet then Samba will accept connections on those
|
|---|
| 97 | links. This may not be what you want.
|
|---|
| 98 | </p><p>
|
|---|
| 99 | You can change this behavior using options like this:
|
|---|
| 100 | </p><table border="0" summary="Simple list" class="simplelist"><tr><td><a class="indexterm" name="id383889"></a><em class="parameter"><code>interfaces = eth* lo</code></em></td></tr><tr><td><a class="indexterm" name="id383901"></a><em class="parameter"><code>bind interfaces only = yes</code></em></td></tr></table><p>
|
|---|
| 101 | </p><p>
|
|---|
| 102 | <a class="indexterm" name="id383915"></a>
|
|---|
| 103 | <a class="indexterm" name="id383922"></a>
|
|---|
| 104 | <a class="indexterm" name="id383929"></a>
|
|---|
| 105 | <a class="indexterm" name="id383936"></a>
|
|---|
| 106 | This tells Samba to listen for connections only on interfaces with a name starting with
|
|---|
| 107 | <code class="constant">eth</code> such as <code class="constant">eth0</code> or <code class="constant">eth1</code>, plus on the loopback interface called
|
|---|
| 108 | <code class="constant">lo</code>. The name you will need to use depends on what OS you are using. In the above, I used
|
|---|
| 109 | the common name for Ethernet adapters on Linux.
|
|---|
| 110 | </p><p>
|
|---|
| 111 | <a class="indexterm" name="id383963"></a>
|
|---|
| 112 | <a class="indexterm" name="id383970"></a>
|
|---|
| 113 | <a class="indexterm" name="id383976"></a>
|
|---|
| 114 | <a class="indexterm" name="id383983"></a>
|
|---|
| 115 | If you use the above and someone tries to make an SMB connection to your host over a PPP interface called
|
|---|
| 116 | <code class="constant">ppp0</code>, then [s]he will get a TCP connection refused reply. In that case, no Samba code
|
|---|
| 117 | is run at all, because the operating system has been told not to pass connections from that interface to any
|
|---|
| 118 | Samba process. However, the refusal helps a would-be cracker by confirming that the IP address provides
|
|---|
| 119 | valid active services.
|
|---|
| 120 | </p><p>
|
|---|
| 121 | <a class="indexterm" name="id384000"></a>
|
|---|
| 122 | <a class="indexterm" name="id384007"></a>
|
|---|
| 123 | <a class="indexterm" name="id384014"></a>
|
|---|
| 124 | <a class="indexterm" name="id384021"></a>
|
|---|
| 125 | <a class="indexterm" name="id384028"></a>
|
|---|
| 126 | A better response would be to ignore the connection (from, for example, ppp0) altogether. The
|
|---|
| 127 | advantage of ignoring the connection attempt, as compared with refusing it, is that it foils those who
|
|---|
| 128 | probe an interface with the sole intention of finding valid IP addresses for later use in exploitation
|
|---|
| 129 | or denial of service attacks. This method of dealing with potential malicious activity demands the
|
|---|
| 130 | use of appropriate firewall mechanisms.
|
|---|
| 131 | </p></div><div class="sect2" title="Using a Firewall"><div class="titlepage"><div><div><h3 class="title"><a name="firewallports"></a>Using a Firewall</h3></div></div></div><p>
|
|---|
| 132 | <a class="indexterm" name="id384051"></a>
|
|---|
| 133 | <a class="indexterm" name="id384058"></a>
|
|---|
| 134 | <a class="indexterm" name="id384065"></a>
|
|---|
| 135 | Many people use a firewall to deny access to services they do not want exposed outside their network. This can
|
|---|
| 136 | be a good idea, although I recommend using it in conjunction with the above methods so you are protected even
|
|---|
| 137 | if your firewall is not active for some reason.
|
|---|
| 138 | </p><p>
|
|---|
| 139 | If you are setting up a firewall, you need to know what TCP and UDP ports to allow and block. Samba uses
|
|---|
| 140 | the following:
|
|---|
| 141 | <a class="indexterm" name="id384078"></a>
|
|---|
| 142 | <a class="indexterm" name="id384085"></a>
|
|---|
| 143 | <a class="indexterm" name="id384092"></a>
|
|---|
| 144 | <a class="indexterm" name="id384099"></a>
|
|---|
| 145 | <a class="indexterm" name="id384106"></a>
|
|---|
| 146 | </p><table border="0" summary="Simple list" class="simplelist"><tr><td>Port 135/TCP - used by smbd</td></tr><tr><td>Port 137/UDP - used by nmbd</td></tr><tr><td>Port 138/UDP - used by nmbd</td></tr><tr><td>Port 139/TCP - used by smbd</td></tr><tr><td>Port 445/TCP - used by smbd</td></tr></table><p>
|
|---|
| 147 | <a class="indexterm" name="id384139"></a>
|
|---|
| 148 | The last one is important because many older firewall setups may not be aware of it, given that this port
|
|---|
| 149 | was only added to the protocol in recent years.
|
|---|
| 150 | </p><p>
|
|---|
| 151 | <a class="indexterm" name="id384151"></a>
|
|---|
| 152 | <a class="indexterm" name="id384157"></a>
|
|---|
| 153 | <a class="indexterm" name="id384164"></a>
|
|---|
| 154 | When configuring a firewall, the high order ports (1024-65535) are often used for outgoing connections and
|
|---|
| 155 | therefore should be permitted through the firewall. It is prudent to block incoming packets on the high order
|
|---|
| 156 | ports except for established connections.
|
|---|
| 157 | </p></div><div class="sect2" title="Using IPC$ Share-Based Denials"><div class="titlepage"><div><div><h3 class="title"><a name="id384176"></a>Using IPC$ Share-Based Denials </h3></div></div></div><p>
|
|---|
| 158 | <a class="indexterm" name="id384183"></a>
|
|---|
| 159 | <a class="indexterm" name="id384190"></a>
|
|---|
| 160 | <a class="indexterm" name="id384197"></a>
|
|---|
| 161 | If the above methods are not suitable, then you could also place a more specific deny on the IPC$ share that
|
|---|
| 162 | is used in the recently discovered security hole. This allows you to offer access to other shares while
|
|---|
| 163 | denying access to IPC$ from potentially untrustworthy hosts.
|
|---|
| 164 | </p><p>
|
|---|
| 165 | To do this you could use:
|
|---|
| 166 | </p><table border="0" summary="Simple list" class="simplelist"><tr><td> </td></tr><tr><td><em class="parameter"><code>[IPC$]</code></em></td></tr><tr><td><a class="indexterm" name="id384224"></a><em class="parameter"><code>hosts allow = 192.168.115.0/24 127.0.0.1</code></em></td></tr><tr><td><a class="indexterm" name="id384236"></a><em class="parameter"><code>hosts deny = 0.0.0.0/0</code></em></td></tr></table><p>
|
|---|
| 167 | </p><p>
|
|---|
| 168 | <a class="indexterm" name="id384251"></a>
|
|---|
| 169 | <a class="indexterm" name="id384257"></a>
|
|---|
| 170 | <a class="indexterm" name="id384264"></a>
|
|---|
| 171 | This instructs Samba that IPC$ connections are not allowed from anywhere except the two listed network
|
|---|
| 172 | addresses (localhost and the 192.168.115 subnet). Connections to other shares are still allowed. Because the
|
|---|
| 173 | IPC$ share is the only share that is always accessible anonymously, this provides some level of protection
|
|---|
| 174 | against attackers who do not know a valid username/password for your host.
|
|---|
| 175 | </p><p>
|
|---|
| 176 | <a class="indexterm" name="id384278"></a>
|
|---|
| 177 | <a class="indexterm" name="id384285"></a>
|
|---|
| 178 | <a class="indexterm" name="id384291"></a>
|
|---|
| 179 | If you use this method, then clients will be given an <code class="literal">`access denied'</code> reply when they try
|
|---|
| 180 | to access the IPC$ share. Those clients will not be able to browse shares and may also be unable to access
|
|---|
| 181 | some other resources. This is not recommended unless for some reason you cannot use one of the other methods
|
|---|
| 182 | just discussed.
|
|---|
| 183 | </p></div><div class="sect2" title="NTLMv2 Security"><div class="titlepage"><div><div><h3 class="title"><a name="id384309"></a>NTLMv2 Security</h3></div></div></div><p>
|
|---|
| 184 | <a class="indexterm" name="id384317"></a>
|
|---|
| 185 | To configure NTLMv2 authentication, the following registry keys are worth knowing about:
|
|---|
| 186 | </p><p>
|
|---|
| 187 | </p><pre class="screen">
|
|---|
| 188 | [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
|
|---|
| 189 | "lmcompatibilitylevel"=dword:00000003
|
|---|
| 190 | </pre><p>
|
|---|
| 191 | </p><p>
|
|---|
| 192 | The value 0x00000003 means to send NTLMv2 response only. Clients will use NTLMv2 authentication;
|
|---|
| 193 | use NTLMv2 session security if the server supports it. Domain controllers accept LM,
|
|---|
| 194 | NTLM, and NTLMv2 authentication.
|
|---|
| 195 | </p><p>
|
|---|
| 196 | </p><pre class="screen">
|
|---|
| 197 | [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
|
|---|
| 198 | "NtlmMinClientSec"=dword:00080000
|
|---|
| 199 | </pre><p>
|
|---|
| 200 | </p><p>
|
|---|
| 201 | The value 0x00080000 means permit only NTLMv2 session security. If either NtlmMinClientSec or
|
|---|
| 202 | NtlmMinServerSec is set to 0x00080000, the connection will fail if NTLMv2
|
|---|
| 203 | session security is negotiated.
|
|---|
| 204 | </p></div></div><div class="sect1" title="Upgrading Samba"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id384357"></a>Upgrading Samba</h2></div></div></div><p>
|
|---|
| 205 | <a class="indexterm" name="id384365"></a>
|
|---|
| 206 | <a class="indexterm" name="id384372"></a>
|
|---|
| 207 | <a class="indexterm" name="id384379"></a>
|
|---|
| 208 | Please check regularly on <a class="ulink" href="http://www.samba.org/" target="_top">http://www.samba.org/</a> for
|
|---|
| 209 | updates and important announcements. Occasionally security releases are made, and it is highly recommended to
|
|---|
| 210 | upgrade Samba promptly when a security vulnerability is discovered. Check with your OS vendor for OS-specific
|
|---|
| 211 | upgrades.
|
|---|
| 212 | </p></div><div class="sect1" title="Common Errors"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id384398"></a>Common Errors</h2></div></div></div><p>
|
|---|
| 213 | If all Samba and host platform configurations were really as intuitive as one might like them to be, this
|
|---|
| 214 | chapter would not be necessary. Security issues are often vexing for a support person to resolve, not because
|
|---|
| 215 | of the complexity of the problem, but because most administrators who post what turns out to be a security
|
|---|
| 216 | problem request are totally convinced that the problem is with Samba.
|
|---|
| 217 | </p><div class="sect2" title="Smbclient Works on Localhost, but the Network Is Dead"><div class="titlepage"><div><div><h3 class="title"><a name="id384413"></a>Smbclient Works on Localhost, but the Network Is Dead</h3></div></div></div><p>
|
|---|
| 218 | This is a common problem. Linux vendors tend to install a default firewall.
|
|---|
| 219 | With the default firewall in place, only traffic on the loopback adapter (IP address 127.0.0.1)
|
|---|
| 220 | is allowed through the firewall.
|
|---|
| 221 | </p><p>
|
|---|
| 222 | The solution is either to remove the firewall (stop it) or modify the firewall script to
|
|---|
| 223 | allow SMB networking traffic through. See <a class="link" href="securing-samba.html#firewallports" title="Using a Firewall">the Using a
|
|---|
| 224 | Firewall</a> section.
|
|---|
| 225 | </p></div><div class="sect2" title="Why Can Users Access Other Users' Home Directories?"><div class="titlepage"><div><div><h3 class="title"><a name="id384437"></a>Why Can Users Access Other Users' Home Directories?</h3></div></div></div><p>
|
|---|
| 226 | <span class="quote">“<span class="quote">
|
|---|
| 227 | <a class="indexterm" name="id384447"></a>
|
|---|
| 228 | <a class="indexterm" name="id384454"></a>
|
|---|
| 229 | We are unable to keep individual users from mapping to any other user's home directory once they have
|
|---|
| 230 | supplied a valid password! They only need to enter their own password. I have not found any method to
|
|---|
| 231 | configure Samba so that users may map only their own home directory.
|
|---|
| 232 | </span>”</span>
|
|---|
| 233 | </p><p><span class="quote">“<span class="quote">
|
|---|
| 234 | User xyzzy can map his home directory. Once mapped, user xyzzy can also map anyone else's home directory.
|
|---|
| 235 | </span>”</span></p><p>
|
|---|
| 236 | <a class="indexterm" name="id384473"></a>
|
|---|
| 237 | <a class="indexterm" name="id384480"></a>
|
|---|
| 238 | This is not a security flaw, it is by design. Samba allows users to have exactly the same access to the UNIX
|
|---|
| 239 | file system as when they were logged on to the UNIX box, except that it only allows such views onto the file
|
|---|
| 240 | system as are allowed by the defined shares.
|
|---|
| 241 | </p><p>
|
|---|
| 242 | <a class="indexterm" name="id384492"></a>
|
|---|
| 243 | <a class="indexterm" name="id384499"></a>
|
|---|
| 244 | If your UNIX home directories are set up so that one user can happily <code class="literal">cd</code>
|
|---|
| 245 | into another user's directory and execute <code class="literal">ls</code>, the UNIX security solution is to change file
|
|---|
| 246 | permissions on the user's home directories so that the <code class="literal">cd</code> and <code class="literal">ls</code> are denied.
|
|---|
| 247 | </p><p>
|
|---|
| 248 | <a class="indexterm" name="id384533"></a>
|
|---|
| 249 | <a class="indexterm" name="id384540"></a>
|
|---|
| 250 | Samba tries very hard not to second guess the UNIX administrator's security policies and
|
|---|
| 251 | trusts the UNIX admin to set the policies and permissions he or she desires.
|
|---|
| 252 | </p><p>
|
|---|
| 253 | Samba allows the behavior you require. Simply put the <a class="link" href="smb.conf.5.html#ONLYUSER" target="_top">only user = %S</a>
|
|---|
| 254 | option in the <em class="parameter"><code>[homes]</code></em> share definition.
|
|---|
| 255 | </p><p>
|
|---|
| 256 | The <a class="link" href="smb.conf.5.html#ONLYUSER" target="_top">only user</a> works in conjunction with the <a class="link" href="smb.conf.5.html#USERS" target="_top">users = list</a>,
|
|---|
| 257 | so to get the behavior you require, add the line:
|
|---|
| 258 | </p><table border="0" summary="Simple list" class="simplelist"><tr><td><a class="indexterm" name="id384601"></a><em class="parameter"><code>users = %S</code></em></td></tr></table><p>
|
|---|
| 259 | This is equivalent to adding
|
|---|
| 260 | </p><table border="0" summary="Simple list" class="simplelist"><tr><td><a class="indexterm" name="id384619"></a><em class="parameter"><code>valid users = %S</code></em></td></tr></table><p>
|
|---|
| 261 | to the definition of the <em class="parameter"><code>[homes]</code></em> share, as recommended in
|
|---|
| 262 | the <code class="filename">smb.conf</code> man page.
|
|---|
| 263 | </p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="locking.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="InterdomainTrusts.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 17. File and Record Locking </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 19. Interdomain Trust Relationships</td></tr></table></div></body></html>
|
|---|
