mountd/statd currently bind to privileged ports to listen for
requests.
This is really a bad thing to do as there is no range of privilege
ports that is guaranteed not to be assigned to some service.
sm-notify probably still needs a privileged port to send out
notifications on, but that should be relatively short lived so
hopefully isn't as much of a problem.
statd needs a privileged port to pass NOTIFY requests down to the
kernel and that is probably the first really good reason I've seen to
replace the rpc interface between lockd and statd.
But if get mountd and statd to default to choosing a non-reserved port
for listening, that would at least decrease the chance that port 631
will be stolen before cupsd gets to bind it.
But is there some reason that mountd/statd need a priv port that I
haven't thought of?
Thanks,
NeilBrown
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Sorry for the delayed response...
Neil Brown wrote:
>
> But is there some reason that mountd/statd need a priv port that I
> haven't thought of?
I don't think so... since neither mountd or statd checks to see
if the source port is a priv port, its not clear why they should
listen on one...
steved.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Monday 16 April 2007 20:13, Steve Dickson wrote:
> > But is there some reason that mountd/statd need a priv port that I
> > haven't thought of?
> I don't think so... since neither mountd or statd checks to see
> if the source port is a priv port, its not clear why they should
> listen on one...
I think portmap let's joe doe replace registrations for non-privileged
ports. Joe Doe can't do that if the port is < 1024.
Denial of service is obvious. The bad things you can do by spoofing
file handles are probably even more interesting: "You want to
mount /diskless/root123? Here, try /home/okir/boobytrapped instead"
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Friday 13 April 2007 03:39, Neil Brown wrote:
> > if that's true, then we could at least rewrite the socket code to bind to
> > ports that do not appear in /etc/services (via getservbyport()) ... that'd
> > allow admins to easily prevent things like mountd/statd from hijacking
> > reserved ports ...
>
> I had thought of that too. I'll probably implement it. Your code (in
> subsequent email) is a little more complicated than needed. Just
> repeatedly call bindresvport, closing if you don't like it. The port
> number tried increments each time.
The glibc shipped with Suse has a file called /etc/bindresvport.blacklist
that you can add ports to. I thought something similar had found its
way upstream by now, but unfortunately I can't find it.
ALTLinux seems to have this patch too.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Tuesday 17 April 2007, Olaf Kirch wrote:
> On Friday 13 April 2007 03:39, Neil Brown wrote:
> > > if that's true, then we could at least rewrite the socket code to bind
> > > to ports that do not appear in /etc/services (via getservbyport()) ...
> > > that'd allow admins to easily prevent things like mountd/statd from
> > > hijacking reserved ports ...
> >
> > I had thought of that too. I'll probably implement it. Your code (in
> > subsequent email) is a little more complicated than needed. Just
> > repeatedly call bindresvport, closing if you don't like it. The port
> > number tried increments each time.
>
> The glibc shipped with Suse has a file called /etc/bindresvport.blacklist
> that you can add ports to. I thought something similar had found its
> way upstream by now, but unfortunately I can't find it.
i thought Drepper already weighed in on this issue with a response similar
to "not a chance in hell" :)
-mike
On Tuesday 17 April 2007, Olaf Kirch wrote:
> On Monday 16 April 2007 20:13, Steve Dickson wrote:
> > > But is there some reason that mountd/statd need a priv port that I
> > > haven't thought of?
> >
> > I don't think so... since neither mountd or statd checks to see
> > if the source port is a priv port, its not clear why they should
> > listen on one...
>
> I think portmap let's joe doe replace registrations for non-privileged
> ports. Joe Doe can't do that if the port is < 1024.
>
> Denial of service is obvious. The bad things you can do by spoofing
> file handles are probably even more interesting: "You want to
> mount /diskless/root123? Here, try /home/okir/boobytrapped instead"
seems like that sort of security is hopelessly outdated in today's networking
world ... if the authentication tuple is {ip,port}, then spoofing would
certainly already be the source of DoS attacks on portmap
-mike
On Tuesday 17 April 2007 13:21, Mike Frysinger wrote:
> seems like that sort of security is hopelessly outdated in today's networking
> world ... if the authentication tuple is {ip,port}, then spoofing would
> certainly already be the source of DoS attacks on portmap
No, pmap_register/unregister must originate from 127.0.0.1, so
this is actually some degree of security.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Fri, 2007-04-13 at 08:05 +1000, Neil Brown wrote:
> mountd/statd currently bind to privileged ports to listen for
> requests.
>
> This is really a bad thing to do as there is no range of privilege
> ports that is guaranteed not to be assigned to some service.
>
> sm-notify probably still needs a privileged port to send out
> notifications on, but that should be relatively short lived so
> hopefully isn't as much of a problem.
>
> statd needs a privileged port to pass NOTIFY requests down to the
> kernel and that is probably the first really good reason I've seen to
> replace the rpc interface between lockd and statd.
>
> But if get mountd and statd to default to choosing a non-reserved port
> for listening, that would at least decrease the chance that port 631
> will be stolen before cupsd gets to bind it.
>
> But is there some reason that mountd/statd need a priv port that I
> haven't thought of?
I usually set statd to '--port 4047 --outgoing-port 4048' and mountd to
'--port 4046'. This more or less mirrors what is apparently the default
setup on NetApp filers (except the --outgoing-port bit) and has worked
pretty well for me.
Cheers
Trond
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thursday 12 April 2007, Neil Brown wrote:
> mountd/statd currently bind to privileged ports to listen for
> requests.
>
> This is really a bad thing to do as there is no range of privilege
> ports that is guaranteed not to be assigned to some service.
s/privilege// ... you have the same problem regardless of privilege state ...
svn/mysql/postgresql/etc... can be just as troublesome for people
redhat has a long standing open bug on the topic with no real workable
solution (the one posted requires a lot of overhad as every package needs
to "opt-in" with the process)
> But is there some reason that mountd/statd need a priv port that I
> haven't thought of?
if that's true, then we could at least rewrite the socket code to bind to
ports that do not appear in /etc/services (via getservbyport()) ... that'd
allow admins to easily prevent things like mountd/statd from hijacking
reserved ports ...
i just wish all the rpc things *asked portmap* for the port so we could put
all of this logic in portmap and not duplicate effort across all rpc
daemons :(
-mike
On Thursday 12 April 2007, Mike Frysinger wrote:
> if that's true, then we could at least rewrite the socket code to bind to
> ports that do not appear in /etc/services (via getservbyport()) ... that'd
> allow admins to easily prevent things like mountd/statd from hijacking
> reserved ports ...
actually, it can be done regardless of how the socket is obtained ... attached
is a function i wrote to address this issue but didnt get around to
integrating into packages
what do you think ?
-mike
On Thursday April 12, [email protected] wrote:
> On Thursday 12 April 2007, Neil Brown wrote:
> > mountd/statd currently bind to privileged ports to listen for
> > requests.
> >
> > This is really a bad thing to do as there is no range of privilege
> > ports that is guaranteed not to be assigned to some service.
>
> s/privilege// ... you have the same problem regardless of privilege state ...
> svn/mysql/postgresql/etc... can be just as troublesome for people
There are supposed to be some ranges which are never assigned.
According to
http://www.iana.org/assignments/port-numbers
DYNAMIC AND/OR PRIVATE PORTS
The Dynamic and/or Private Ports are those from 49152 through 65535
as long as we choose one of those (and that is what happens if you
just let the kernel decide for you) there must be no conflict.
>
> if that's true, then we could at least rewrite the socket code to bind to
> ports that do not appear in /etc/services (via getservbyport()) ... that'd
> allow admins to easily prevent things like mountd/statd from hijacking
> reserved ports ...
I had thought of that too. I'll probably implement it. Your code (in
subsequent email) is a little more complicated than needed. Just
repeatedly call bindresvport, closing if you don't like it. The port
number tried increments each time.
Thanks,
NeilBrown
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thursday 12 April 2007, Neil Brown wrote:
> There are supposed to be some ranges which are never assigned.
> According to
> http://www.iana.org/assignments/port-numbers
>
> DYNAMIC AND/OR PRIVATE PORTS
>
> The Dynamic and/or Private Ports are those from 49152 through 65535
>
> as long as we choose one of those (and that is what happens if you
> just let the kernel decide for you) there must be no conflict.
hmm, true ... that is much simpler to grab random ports in that range :)
> I had thought of that too. I'll probably implement it. Your code (in
> subsequent email) is a little more complicated than needed. Just
> repeatedly call bindresvport, closing if you don't like it. The port
> number tried increments each time.
is that guaranteed somewhere ? when i first worked on the code snippet, i
looked for such info and since i couldnt locate any such "the implementation
must increment" requirement, i felt the more complicated recursive approach
is better since relying on Linux/glibc behavior is not appropriate ...
-mike