Host access philosophy (Was: restricting NFS (and associated services) to one IP address)

[Steven M. Bellovin]

That's certainly one approach, though we'd need checkinterface set as well.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Byron Servies]

The first is to incorporate access control semantics into
rpcbind. It's
not a horrible solution, in that it provides some protection against
attackers who first query rpcbind to find out what port numbers to
attack.

I've already said something analogous in private email, but I'll share
it, I suppose, with the list.
I do not think that "access control" semantics in particular
applications
are quite what is wanted, here, if you mean "access control by
address of
requesting party" which is what most people, I think, would assume you
mean.
What you want, as far as I can tell, is access control at the
granularity
merely of "reachability from directly-connected network N".
Assuring that
unauthorized parties have no connectivity to N is a problem you're
willing
to place out of scope for your present effort. Firewalls (including
IP-layer filtering on the local host) can give you this, but
configuring
them for protocols that use dynamic port addressing can be a real
nuisance.

I freely admit I am out of my depth, but wasn't NFSv4 designed to
solve a lot of these long-standing NFS problems?

http://www.ietf.org/rfc/rfc3530.txt

Byron

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Andy Ruhl]

Post by Byron Servies
I freely admit I am out of my depth, but wasn't NFSv4 designed to
solve a lot of these long-standing NFS problems?

(Me too, but you never learn anything by hanging out with people who
tell you stuff you already know. :)

I think NFS4 isn't the only answer though. There's AFS too, and other
variants. I don't think NFS4 should necessarily be the "next"
networked filesystem that NetBSD uses simply because it's called NFS,
but I haven't really done my NFS4 homework either.

This subject probably has the ability to get way too big inside this
thread. It probably already has.

Seems like there are too many ways to solve these types of problems,
depending on preference, application, etc. I'm probably not smart
enough to make this statement, but when one starts really considering
how to solve these problems in some sort of unified way, Plan9 seems
to make more and more sense.

But then, I don't think anyone is really requiring unity, just some
good solution for their particular situation and preference. Or maybe
I'm missing something?

Seems like I've opened a can of worms here, which I didn't mean to do.
My comment earlier about having some sort of firewall software
included with an operating system really is only a reaction to the
idea that one would have to block a port with a "firewall" in order to
run an application which can't control it's use of IP addresses or
ports. I think this is common, and it's kind of sad. It's the only
simple solution I found to the original subject though.

Andy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matthias Scheler]

Post by Byron Servies
I freely admit I am out of my depth, but wasn't NFSv4 designed to
solve a lot of these long-standing NFS problems?

The security of NFSv3 isn't that bad if you implementent all the
security related extensions (e.g. Kerberos authentification).
Unfortunately most implementations don't which is why those
extensions are required in NFSv4.

I think NFS4 isn't the only answer though. There's AFS too, ...

I don't know AFS very well. Why was the BSD version never integrated
in e.g. NetBSD or FreeBSD? It seems to be in the Linux 2.6.18 kernel.

... and other variants. I don't think NFS4 should necessarily be the "next"
networked filesystem that NetBSD uses simply because it's called NFS,

I'm not aware that NetBSD is somehow limited to support only one
network filesystem. It will support as many network filesystems
as somebody wrote the necessary code for. The reasone that NFSv[23]
is currently the prefered network filesystem is because is has the
best implementation (kernel client and server, bootloaders, etc.).
If you want to use another network filesystem write the code for
it and submit it, please.

but I haven't really done my NFS4 homework either.

One of the nice aspects of NFSv[23] is that most operating system support
it out of the box. It is my impression that NFSv4 might get their
eventually which would make it the obvious choice.

Kind regards

[Jonathan A. Kollasch]

Post by Matthias Scheler

I think NFS4 isn't the only answer though. There's AFS too, ...

I don't know AFS very well. Why was the BSD version never integrated
in e.g. NetBSD or FreeBSD? It seems to be in the Linux 2.6.18 kernel.

https://lists.stacken.kth.se/pipermail/arla-drinkers/2006-June/003937.html

Arla has recently grown block-cache support on OS X, and should
be able to be adapted to work on the other platforms Arla
supports as well.

OpenAFS is the most desirable client, but it doesn't have completed
support for NetBSD.

Linux's in-tree AFS support is (hmm, how to put this nicely) -- bad.
It doesn't have a client-side cache, it doesn't do authentication
at all, etc, etc.

Jonathan Kollasch

[Love Hörnquist Åstrand]

Post by Matthias Scheler
I don't know AFS very well. Why was the BSD version never integrated
in e.g. NetBSD or FreeBSD? It seems to be in the Linux 2.6.18 kernel.

I've not pushed for a integration of arla into NetBSD for arla grew
block
caching. In fact I've pushed back request to integrate it.

Love



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matthew Orgass]

Thor> I think that if we provided sane primitives for discovering
Thor> the set of valid destination addresses for a host, and binding
Thor> a socket so that it would receive packets on _some addresses_
Thor> (not one, and not all) it would be easy to add the kind of
Thor> access control you seem to want (and which a lot of other
Thor> people would probably like as well) to our applications.
Thor> In this case, we would add it to mountd, rpcbind, and the
Thor> in-kernel NFS server. It would be a nice example of the
Thor> interface, actually.
I agree strongly.

But should individual applications need to know about it? An
alternative would be to let, say, inetd determine this even for separate
servers and provide a notification interface if the server really needs to
know what interface/address(s) it is listening on.

Matthew Orgass
***@city-net.com


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thor> I think that if we provided sane primitives for discovering
Thor> the set of valid destination addresses for a host, and binding
Thor> a socket so that it would receive packets on _some addresses_
Thor> (not one, and not all) it would be easy to add the kind of
Thor> access control you seem to want (and which a lot of other
Thor> people would probably like as well) to our applications.

Thor> In this case, we would add it to mountd, rpcbind, and the
Thor> in-kernel NFS server. It would be a nice example of the
Thor> interface, actually.

I agree strongly.

Matthew> But should individual applications need to know about it?

The "127.0.0.2" hack means that an application can pick one of three
things:
a) 0.0.0.0 (present case)
b) specific IP (often available, but NOT ALWAYS)

Our mountd/etc. needs to have (b) added, at a minimum.

Matthew> An alternative would be to let, say, inetd determine this
Matthew> even for separate servers and provide a notification
Matthew> interface if the server really needs to know what
Matthew> interface/address(s) it is listening on.

That sounds really complicated, but maybe I'm mis-understanding you.

- --
] Bear: "Me, I'm just the shape of a bear." | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] ***@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRS1nFICLcPvd0N1lAQLQlgf/SNsCSTg0pXvJveR+h3x9nKGKzruioIOZ
iapbbtmM89N3oQXuztV2dxw0ZxqE5h6cCs5/cmmyR/bJsqcsvk9OHpbpTCZjiI6i
AP4iBcz4IuCRGOYBi6ckAAh1vp+w1K+VZ5NUfB6L+QiVC8TqKhioQJXQrZZFyWmN
ycahdaC0Xk8Y3yvcWiJbiBw9pggrZ+FnaYDkXvsTkTXjxHi9YBdd3KvbkUNHMzUO
mev7EfuAJa/fr6J66lCA0MKyOl8xfpFE9noAgW5+djpVILE6RXaTYmlrROSm1/i1
+5TvRmjNj4yYiEpOY46ntTysQFGnu0dXt7HfuOXBhFxTKkO7bOlOBA==
=C98M
-----END PGP SIGNATURE-----

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de