Dirk Wetter wrote:
>>> Is this a regression or is my memory wrong?
>> Your memory is correct. Secure by Default leaves rcpbind enabled (so
>> nmap will show port 111 as open), but it will only accept requests from
>> the local system. You can verify that rpcbind is in local-only mode as
>> follows:
>>
>> # svccfg -s rpc/bind listprop config/local_only
>> config/local_only boolean true
>
> You hit the nail on the head: it's set to false and I didn't change it, see
> below.
>
>> So your nmap output is not surprising,
>
> nmap -A checks amongst other things also the service behind it if a port
> appears to be open. Otherwise you wouldn't get the prog# of RPC services
> and the version of SSH used ;-)
Sorry, I didn't look closely enough at your nmap output. My point was
that we would expect nmap to show that rpcbind is listening, even if
config/local_only is set to true.
>
>> but rpcinfo from a remote system should look like this:
>>
>> $ rpcinfo -p remotehost
>> rpcinfo: can't contact portmapper: RPC: Authentication error; why =
>> Failed (unspecified error)
>
> Well, yes, this is what I would have expected.
>
> Which system?
I produced the output above with a server running Nevada build 62.
Should be the same for any post-SBD system.
>
>> Since your system is responding to remote rpcinfo requests, it appears
>> that config/local_only is set to false. This may have occurred as a side
>> effect of enabling other services that require rpcbind. For example,
>> mounting or exporting an NFS file system would have this effect.
>
> That's my point. It didn't set that manually, at least not that I am
> aware of.
>
> One script during my post installation could have used the box as an NFS
> client though, if this is what you meant by side effect.
>
> But a) system configurations should not change on the fly w/ the admin's
> knowledge b) NFS *clients* should not need a portmapper which is
> accessible from remote.
I see your point. However, the principle we followed for Secure by
Default was to ensure that network ports were not opened without
*action* from the administrator, though action does not necessarily
imply *knowledge*. In other words, you had to take explicit action to
cause the NFS mount, but you might not have known that it would enable
rpcbind as a side effect.
Even an NFS client requires lockd and statd in order to implement
correct file locking semantics, and that's why rpcbind is needed.
Scott
