Does Qnet attempt to enforce any security?
I seem to be able to use it to directly migrate root priviliges between
QNXRTP (6.1) machines. That is logging on as root on one machine gives me
root acess to any machines running Qnet. This is despite none of the
machines having the same root password.
All very strange. The npm-qnet.so is singularly quiet on the issue of
security.
Michael Stevens
“Michael Stevens” <michael@acrfr.usyd.edu.au> wrote in message
news:9jgpk8$gdh$1@inn.qnx.com…
Does Qnet attempt to enforce any security?
I seem to be able to use it to directly migrate root priviliges between
QNXRTP (6.1) machines. That is logging on as root on one machine gives me
root acess to any machines running Qnet. This is despite none of the
machines having the same root password.
That is indeed the case. Historicaly QNX has always been like that.
All very strange. The npm-qnet.so is singularly quiet on the issue of
security.
Apparently the protocol they use has some provisition to solve that
issue but I guess they have other priorities.
Michael Stevens
\
Of course Qnet has no inter-machine security. The whole point of Qnet
is to merge all of the individual machines on the network into one
machine, thus you have the same security as if you had one machine (i.e.
if you are root, you are root regardless of which microprocessor ran the
initial authentication code - think of an SMP machine, would you want to
have to log in to each processor before you could use them ? - this
would severely reduce the utility of SMP don’t you think ?).
If you want to continue to look at each node as an isolated entity with
it’s own security domain, then simply use the conventional TCP/IP suite.
Qnet is designed to be used on small local area networks (even backplane
networks) where a cohesive distributed real-time system is desired. One
can assign a “Qnet” a single IP address, and treat it, in every way, as
a single node on a larger TCP/IP network (just as a collection of four
processors in an SMP machine are treated as a single node on a TCP/IP
network).
-----Original Message-----
From: Michael Stevens [mailto:michael@acrfr.usyd.edu.au]
Posted At: Monday, July 23, 2001 2:14 AM
Posted To: os
Conversation: QNet security, does it have any!!
Subject: QNet security, does it have any!!
Does Qnet attempt to enforce any security?
I seem to be able to use it to directly migrate root priviliges between
QNXRTP (6.1) machines. That is logging on as root on one machine gives
me
root acess to any machines running Qnet. This is despite none of the
machines having the same root password.
All very strange. The npm-qnet.so is singularly quiet on the issue of
security.
Michael Stevens
I would agree Rennie, if QNX also provided a way to share user accounts
across QNET. A network-wide authentication server would be nice, otherwise
problem of equivalency of user accounts makes situation rather bad.
“Rennie Allen” <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C9061821@exchangecal.hq.csical.com…
Of course Qnet has no inter-machine security. The whole point of Qnet
is to merge all of the individual machines on the network into one
machine, thus you have the same security as if you had one machine (i.e.
if you are root, you are root regardless of which microprocessor ran the
initial authentication code - think of an SMP machine, would you want to
have to log in to each processor before you could use them ? - this
would severely reduce the utility of SMP don’t you think ?).If you want to continue to look at each node as an isolated entity with
it’s own security domain, then simply use the conventional TCP/IP suite.
Qnet is designed to be used on small local area networks (even backplane
networks) where a cohesive distributed real-time system is desired. One
can assign a “Qnet” a single IP address, and treat it, in every way, as
a single node on a larger TCP/IP network (just as a collection of four
processors in an SMP machine are treated as a single node on a TCP/IP
network).-----Original Message-----
From: Michael Stevens [mailto:> michael@acrfr.usyd.edu.au> ]
Posted At: Monday, July 23, 2001 2:14 AM
Posted To: os
Conversation: QNet security, does it have any!!
Subject: QNet security, does it have any!!
Does Qnet attempt to enforce any security?I seem to be able to use it to directly migrate root priviliges between
QNXRTP (6.1) machines. That is logging on as root on one machine gives
me
root acess to any machines running Qnet. This is despite none of the
machines having the same root password.All very strange. The npm-qnet.so is singularly quiet on the issue of
security.Michael Stevens
\
ln -sP /net/password_server/etc/passwd /etc/passwd ?
Is there some reason this won’t work ? The above method worked fine for
QNX4.
-----Original Message-----
From: Igor Kovalenko [mailto:kovalenko@home.com]
Posted At: Monday, July 23, 2001 12:00 PM
Posted To: os
Conversation: QNet security, does it have any!!
Subject: Re: QNet security, does it have any!!
I would agree Rennie, if QNX also provided a way to share user accounts
across QNET. A network-wide authentication server would be nice,
otherwise
problem of equivalency of user accounts makes situation rather bad.
“Rennie Allen” <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C9061821@exchangecal.hq.csical.com…
Of course Qnet has no inter-machine security. The whole point of Qnet
is to merge all of the individual machines on the network into one
machine, thus you have the same security as if you had one machine
(i.e.
if you are root, you are root regardless of which microprocessor ran
the
initial authentication code - think of an SMP machine, would you want
to
have to log in to each processor before you could use them ? - this
would severely reduce the utility of SMP don’t you think ?).If you want to continue to look at each node as an isolated entity
with
it’s own security domain, then simply use the conventional TCP/IP
suite.
Qnet is designed to be used on small local area networks (even
backplane
networks) where a cohesive distributed real-time system is desired.
One
can assign a “Qnet” a single IP address, and treat it, in every way,
as
a single node on a larger TCP/IP network (just as a collection of four
processors in an SMP machine are treated as a single node on a TCP/IP
network).-----Original Message-----
From: Michael Stevens [mailto:> michael@acrfr.usyd.edu.au> ]
Posted At: Monday, July 23, 2001 2:14 AM
Posted To: os
Conversation: QNet security, does it have any!!
Subject: QNet security, does it have any!!
Does Qnet attempt to enforce any security?I seem to be able to use it to directly migrate root priviliges
between
QNXRTP (6.1) machines. That is logging on as root on one machine gives
me
root acess to any machines running Qnet. This is despite none of the
machines having the same root password.All very strange. The npm-qnet.so is singularly quiet on the issue of
security.Michael Stevens
\
You generally need a fallback mechanism for any kind of server. If the
password_server fails noone would be able to authenticate, which is not
acceptable in most environments. Remember how QNX4 could run several
namelocs? And you can have several DNS servers, DHCP servers, etc…
Besides an authentication server could be smarter than that. It could do
mapping between accounts, to implement ‘root squash’ or other things, based
on origin of request (local or remote).
“Rennie Allen” <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C9061A37@exchangecal.hq.csical.com…
ln -sP /net/password_server/etc/passwd /etc/passwd ?
Is there some reason this won’t work ? The above method worked fine for
QNX4.-----Original Message-----
From: Igor Kovalenko [mailto:> kovalenko@home.com> ]
Posted At: Monday, July 23, 2001 12:00 PM
Posted To: os
Conversation: QNet security, does it have any!!
Subject: Re: QNet security, does it have any!!
I would agree Rennie, if QNX also provided a way to share user accounts
across QNET. A network-wide authentication server would be nice,
otherwise
problem of equivalency of user accounts makes situation rather bad.
- igor
“Rennie Allen” <> RAllen@csical.com> > wrote in message
news:> D4907B331846D31198090050046F80C9061821@exchangecal.hq.csical.com> …
Of course Qnet has no inter-machine security. The whole point of Qnet
is to merge all of the individual machines on the network into one
machine, thus you have the same security as if you had one machine
(i.e.
if you are root, you are root regardless of which microprocessor ran
the
initial authentication code - think of an SMP machine, would you want
to
have to log in to each processor before you could use them ? - this
would severely reduce the utility of SMP don’t you think ?).If you want to continue to look at each node as an isolated entity
with
it’s own security domain, then simply use the conventional TCP/IP
suite.
Qnet is designed to be used on small local area networks (even
backplane
networks) where a cohesive distributed real-time system is desired.
One
can assign a “Qnet” a single IP address, and treat it, in every way,
as
a single node on a larger TCP/IP network (just as a collection of four
processors in an SMP machine are treated as a single node on a TCP/IP
network).-----Original Message-----
From: Michael Stevens [mailto:> michael@acrfr.usyd.edu.au> ]
Posted At: Monday, July 23, 2001 2:14 AM
Posted To: os
Conversation: QNet security, does it have any!!
Subject: QNet security, does it have any!!
Does Qnet attempt to enforce any security?I seem to be able to use it to directly migrate root priviliges
between
QNXRTP (6.1) machines. That is logging on as root on one machine gives
me
root acess to any machines running Qnet. This is despite none of the
machines having the same root password.All very strange. The npm-qnet.so is singularly quiet on the issue of
security.Michael Stevens
\
Igor Kovalenko <kovalenko@home.com> wrote:
You generally need a fallback mechanism for any kind of server. If the
password_server fails noone would be able to authenticate, which is not
acceptable in most environments. Remember how QNX4 could run several
namelocs? And you can have several DNS servers, DHCP servers, etc…Besides an authentication server could be smarter than that. It could do
mapping between accounts, to implement ‘root squash’ or other things, based
on origin of request (local or remote).
The “fallback server” is under consideration of “next QNET”, but I have a
feeling that the “next generation super fs-pkg” will handle this kind of
fallback, or “root squash” 
Thomas can correct me if I am worng.
-xtang
“Rennie Allen” <> RAllen@csical.com> > wrote in message
news:> D4907B331846D31198090050046F80C9061A37@exchangecal.hq.csical.com> …
ln -sP /net/password_server/etc/passwd /etc/passwd ?Is there some reason this won’t work ? The above method worked fine for
QNX4.-----Original Message-----
From: Igor Kovalenko [mailto:> kovalenko@home.com> ]
Posted At: Monday, July 23, 2001 12:00 PM
Posted To: os
Conversation: QNet security, does it have any!!
Subject: Re: QNet security, does it have any!!
I would agree Rennie, if QNX also provided a way to share user accounts
across QNET. A network-wide authentication server would be nice,
otherwise
problem of equivalency of user accounts makes situation rather bad.
- igor
“Rennie Allen” <> RAllen@csical.com> > wrote in message
news:> D4907B331846D31198090050046F80C9061821@exchangecal.hq.csical.com> …
Of course Qnet has no inter-machine security. The whole point of Qnet
is to merge all of the individual machines on the network into one
machine, thus you have the same security as if you had one machine
(i.e.
if you are root, you are root regardless of which microprocessor ran
the
initial authentication code - think of an SMP machine, would you want
to
have to log in to each processor before you could use them ? - this
would severely reduce the utility of SMP don’t you think ?).If you want to continue to look at each node as an isolated entity
with
it’s own security domain, then simply use the conventional TCP/IP
suite.
Qnet is designed to be used on small local area networks (even
backplane
networks) where a cohesive distributed real-time system is desired.
One
can assign a “Qnet” a single IP address, and treat it, in every way,
as
a single node on a larger TCP/IP network (just as a collection of four
processors in an SMP machine are treated as a single node on a TCP/IP
network).-----Original Message-----
From: Michael Stevens [mailto:> michael@acrfr.usyd.edu.au> ]
Posted At: Monday, July 23, 2001 2:14 AM
Posted To: os
Conversation: QNet security, does it have any!!
Subject: QNet security, does it have any!!
Does Qnet attempt to enforce any security?I seem to be able to use it to directly migrate root priviliges
between
QNXRTP (6.1) machines. That is logging on as root on one machine gives
me
root acess to any machines running Qnet. This is despite none of the
machines having the same root password.All very strange. The npm-qnet.so is singularly quiet on the issue of
security.Michael Stevens
\
Well, for the kind of systems I work on, failure of one element (I say
element because a node is actually a redundant pair of CPU’s - i.e. in
order for the element to fail both redundant CPU’s must fail)
constitutes failure of the entire system; thus if the password server
isn’t there, then by definition it isn’t required. As I said Qnet is
primarily aimed at small tightly coupled systems (where all the
“elements” are required for the device to operate). There is nothing
wrong with having the kind of functionality you are asking for, but
there is a massive set of applications that Qnet already addresses
adequately (from a design feature POV - what I want to see is a robust
implementation of the current Qnet feature set 
I think that if you are looking at Qnet for large, loosely coupled
networks of computers, you are using the wrong tool for the job (the
TCP/IP suite seems to address this problem domain adequately).
-----Original Message-----
From: Igor Kovalenko [mailto:kovalenko@home.com]
Posted At: Monday, July 23, 2001 8:59 PM
Posted To: os
Conversation: QNet security, does it have any!!
Subject: Re: QNet security, does it have any!!
You generally need a fallback mechanism for any kind of server. If the
password_server fails noone would be able to authenticate, which is not
acceptable in most environments. Remember how QNX4 could run several
namelocs? And you can have several DNS servers, DHCP servers, etc…
Besides an authentication server could be smarter than that. It could do
mapping between accounts, to implement ‘root squash’ or other things,
based
on origin of request (local or remote).
“Rennie Allen” <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C9061A37@exchangecal.hq.csical.com…
ln -sP /net/password_server/etc/passwd /etc/passwd ?
Is there some reason this won’t work ? The above method worked fine
for
QNX4.-----Original Message-----
From: Igor Kovalenko [mailto:> kovalenko@home.com> ]
Posted At: Monday, July 23, 2001 12:00 PM
Posted To: os
Conversation: QNet security, does it have any!!
Subject: Re: QNet security, does it have any!!
I would agree Rennie, if QNX also provided a way to share user
accounts
across QNET. A network-wide authentication server would be nice,
otherwise
problem of equivalency of user accounts makes situation rather bad.
- igor
“Rennie Allen” <> RAllen@csical.com> > wrote in message
news:> D4907B331846D31198090050046F80C9061821@exchangecal.hq.csical.com> …
Of course Qnet has no inter-machine security. The whole point of
Qnet
is to merge all of the individual machines on the network into one
machine, thus you have the same security as if you had one machine
(i.e.
if you are root, you are root regardless of which microprocessor ran
the
initial authentication code - think of an SMP machine, would you
want
to
have to log in to each processor before you could use them ? - this
would severely reduce the utility of SMP don’t you think ?).If you want to continue to look at each node as an isolated entity
with
it’s own security domain, then simply use the conventional TCP/IP
suite.
Qnet is designed to be used on small local area networks (even
backplane
networks) where a cohesive distributed real-time system is desired.
One
can assign a “Qnet” a single IP address, and treat it, in every way,
as
a single node on a larger TCP/IP network (just as a collection of
four
processors in an SMP machine are treated as a single node on a
TCP/IP
network).-----Original Message-----
From: Michael Stevens [mailto:> michael@acrfr.usyd.edu.au> ]
Posted At: Monday, July 23, 2001 2:14 AM
Posted To: os
Conversation: QNet security, does it have any!!
Subject: QNet security, does it have any!!
Does Qnet attempt to enforce any security?I seem to be able to use it to directly migrate root priviliges
between
QNXRTP (6.1) machines. That is logging on as root on one machine
gives
me
root acess to any machines running Qnet. This is despite none of the
machines having the same root password.All very strange. The npm-qnet.so is singularly quiet on the issue
of
security.Michael Stevens
\
In a conversation I heard at the last QNX conference, it was
admitted that there was a lot of work to do with respect to
security on the network. Users who might be visible on the
internet were warned that because RTP QNET rides over IP, it
was theoretically possible for a hacker to grab root
priviledges on an RTP system over the internet. This is
unlikely for a number of reasons, and easily thwarted by
hiding behind some form of firewall.
The point however is that this is an area that QSSL
has plans for, but just hasn’t implemented yet. I would
be surprised if later versions do not have any form
of QNX peer to peer security. This would of course be
optional.
Previously, Michael Stevens wrote in qdn.public.qnxrtp.os:
Does Qnet attempt to enforce any security?
I seem to be able to use it to directly migrate root priviliges between
QNXRTP (6.1) machines. That is logging on as root on one machine gives me
root acess to any machines running Qnet. This is despite none of the
machines having the same root password.All very strange. The npm-qnet.so is singularly quiet on the issue of
security.Michael Stevens
\
–
Mitchell Schoenbrun --------- maschoen@pobox.com
QNET does not ride on top of IP by default anymore (since 6.1).
“Mitchell Schoenbrun” <maschoen@pobox.com> wrote in message
news:Voyager.010724130527.281F@schoenbrun.com…
In a conversation I heard at the last QNX conference, it was
admitted that there was a lot of work to do with respect to
security on the network. Users who might be visible on the
internet were warned that because RTP QNET rides over IP, it
was theoretically possible for a hacker to grab root
priviledges on an RTP system over the internet. This is
unlikely for a number of reasons, and easily thwarted by
hiding behind some form of firewall.The point however is that this is an area that QSSL
has plans for, but just hasn’t implemented yet. I would
be surprised if later versions do not have any form
of QNX peer to peer security. This would of course be
optional.
Previously, Michael Stevens wrote in qdn.public.qnxrtp.os:
Does Qnet attempt to enforce any security?I seem to be able to use it to directly migrate root priviliges between
QNXRTP (6.1) machines. That is logging on as root on one machine gives
me
root acess to any machines running Qnet. This is despite none of the
machines having the same root password.All very strange. The npm-qnet.so is singularly quiet on the issue of
security.Michael Stevens
\Mitchell Schoenbrun --------- > maschoen@pobox.com
Previously, Igor Kovalenko wrote in qdn.public.qnxrtp.os:
QNET does not ride on top of IP by default anymore (since 6.1).
So they made it an option eh? Was this just a quick fix, or do
you know if they’ve done any other work for 6.1?
Mitchell Schoenbrun --------- maschoen@pobox.com
“Mitchell Schoenbrun” <maschoen@pobox.com> wrote in message
news:Voyager.010726123039.5363B@schoenbrun.com…
Previously, Igor Kovalenko wrote in qdn.public.qnxrtp.os:
QNET does not ride on top of IP by default anymore (since 6.1).
So they made it an option eh? Was this just a quick fix, or do
you know if they’ve done any other work for 6.1?
I think it was intentional change to avoid secutity issues with QNET.
Release notes also say pulses and signals can now cross node boundaries,
although they don’t give a slightest hint how to send signal to different
node. I guess it can be done through one of debug devctl()s into remote
procfs but they sure did not mean that, lol
Igor Kovalenko <kovalenko@home.com> wrote:
Release notes also say pulses and signals can now cross node boundaries,
although they don’t give a slightest hint how to send signal to different
node. I guess it can be done through one of debug devctl()s into remote
procfs but they sure did not mean that, lol >
Brian Stecher (bstecher@qnx.com) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8
Igor Kovalenko <kovalenko@home.com> wrote:
“Mitchell Schoenbrun” <> maschoen@pobox.com> > wrote in message
news:> Voyager.010726123039.5363B@schoenbrun.com> …
Previously, Igor Kovalenko wrote in qdn.public.qnxrtp.os:QNET does not ride on top of IP by default anymore (since 6.1).
So they made it an option eh? Was this just a quick fix, or do
you know if they’ve done any other work for 6.1?
I think it was intentional change to avoid secutity issues with QNET.
Release notes also say pulses and signals can now cross node boundaries,
although they don’t give a slightest hint how to send signal to different
node. I guess it can be done through one of debug devctl()s into remote
procfs but they sure did not mean that, lol >
For utils, you use “slay -n node process_name”. For program, you
use “SignalKill(nd, pid, tid, signo, code, value)”.
-xtang
“Brian Stecher” <bstecher@qnx.com> wrote in message
news:9jrslk$9db$1@nntp.qnx.com…
Igor Kovalenko <> kovalenko@home.com> > wrote:
Release notes also say pulses and signals can now cross node boundaries,
although they don’t give a slightest hint how to send signal to
different
node. I guess it can be done through one of debug devctl()s into remote
procfs but they sure did not mean that, lol >SignalKill() with a non-zero node descriptor, perhaps? >
Hummm. That doesn’t smell exactly like ‘transparent’ networking, does it? An
application needs to be very much aware about network to do it…
What I’m thinking is a concept of ‘network root’ which could be set either
externally or by process itself and would make some calls be routed to
remote nodes. It is almost doable by the trick with reopening SYSMGR_COID
suggested by cdm, but the fact that MEMMGR_COID == SYSMGR_COID does not
help.
Igor Kovalenko <kovalenko@home.com> wrote:
“Brian Stecher” <> bstecher@qnx.com> > wrote in message
news:9jrslk$9db$> 1@nntp.qnx.com> …
Igor Kovalenko <> kovalenko@home.com> > wrote:
Release notes also say pulses and signals can now cross node boundaries,
although they don’t give a slightest hint how to send signal to
different
node. I guess it can be done through one of debug devctl()s into remote
procfs but they sure did not mean that, lol >SignalKill() with a non-zero node descriptor, perhaps? >
Hummm. That doesn’t smell exactly like ‘transparent’ networking, does it? An
application needs to be very much aware about network to do it…
Well, i guess that’s posix signal (or the whole unix) don’t have
“network” concept. Lots of things are based on “old good” pid only…
What I’m thinking is a concept of ‘network root’ which could be set either
externally or by process itself and would make some calls be routed to
remote nodes. It is almost doable by the trick with reopening SYSMGR_COID
suggested by cdm, but the fact that MEMMGR_COID == SYSMGR_COID does not
help.
The application still have to aware “which netroot” to switch to, no?
Idealy, “chroot()” give you what you want. If you “chroot(/net/him)”,
everything you “open()” is under /net/him.
The problem is those hard coded COIDs, we really need to re-think
about these COIDs
-xtang
“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:9kadk4$9v7$2@nntp.qnx.com…
Igor Kovalenko <> kovalenko@home.com> > wrote:
Well, i guess that’s posix signal (or the whole unix) don’t have
“network” concept. Lots of things are based on “old good” pid only…
You could come up with ‘virtual pid’ like in QNX4. I.e., there could be a
pid corresponding to aprocess on another node… Of course it’d need to be
established, but establishing connection once is still much better than
hacking code all over to make it ‘network aware’.
What I’m thinking is a concept of ‘network root’ which could be set
either
externally or by process itself and would make some calls be routed to
remote nodes. It is almost doable by the trick with reopening
SYSMGR_COID
suggested by cdm, but the fact that MEMMGR_COID == SYSMGR_COID does not
help.The application still have to aware “which netroot” to switch to, no?
The libc could use some environment variable…
Idealy, “chroot()” give you what you want. If you “chroot(/net/him)”,
everything you “open()” is under /net/him.
Well chroot() is not supposed to let you out of new root once you’re in, is
it?
I’d like ability to change network roots on the fly
The problem is those hard coded COIDs, we really need to re-think
about these COIDs
Yes, hardcoded sever connection IDs are real shame.