qnet questions and beyond

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

Hi boys. I’ve some security-related questions for you :slight_smile:.
I’ve read the qnet chapter in the reference but I’ve not understand
if qnet effectively relyes on the IP protocol? Or simply uses
directly datagrams to communicate through the lines?

If it relyes on IP (or udp) what precautions I should take care of
if a qnx machine will be used as a http server over a tcp link?
(probably under ppp, maybe it offers some kind of security).
Should I put it behind a firewall? Which ports should I iron out?
Could the ipfilter package for io-net suffice?

Another one… every machine in a lan is avaible under /net.
Is the complete filesystem avaible? If so, what kind of security
have users of machine “a” if machine “b” can access every file on
it? Does Qnx prevents of having 2 identical users on 2 different machines
on the same lan?

How I could exclude a single machine for being resolved under /net
under my lan? Or could I exclude a single path (say /home) from being
shared?

I’m still confused. The network seems to not have any security!

Thanks in advance

–
John [ipv7.net]

2

john@broadcast.ipv7.net wrote:

Hi boys. I’ve some security-related questions for you > :slight_smile:> .
I’ve read the qnet chapter in the reference but I’ve not understand
if qnet effectively relyes on the IP protocol? Or simply uses
directly datagrams to communicate through the lines?

If it relyes on IP (or udp) what precautions I should take care of
if a qnx machine will be used as a http server over a tcp link?
(probably under ppp, maybe it offers some kind of security).
Should I put it behind a firewall? Which ports should I iron out?
Could the ipfilter package for io-net suffice?

Another one… every machine in a lan is avaible under /net.
Is the complete filesystem avaible? If so, what kind of security
have users of machine “a” if machine “b” can access every file on
it? Does Qnx prevents of having 2 identical users on 2 different machines
on the same lan?

How I could exclude a single machine for being resolved under /net
under my lan? Or could I exclude a single path (say /home) from being
shared?

I’m still confused. The network seems to not have any security!

It is almost true :slight_smile:

First, QNET using IP protocal 106, so you could setup your firewall
to exclude these IP to protect your internal QNET packet fly out.
QNET also have a “bind=ether” option (which is default), this force
QNET only using LAN.

As for access control, like somebody else already pointed out,
QNET is designed to “connect several nodes so they are virtually
one big machine”. Once connect, any service a node have (file system
is one service) is opened to the whole “QNET network”. The only
“security” could have, is decided by the server who provide that
service.

For your filesystem sample, once on QNET, anybody could access
other nodes “/” or “/home” (they are in one big machine now),
but the usual file system permission still works, so, if you
are “smith”, on node A, you probably won’t be able to access
node B’s /home/joe.

Add some sort of access control in QNET (like never talk to “that
node”) is under consideration, but it is not in a high priority.

-xtang

3

Xiaodan Tang <xtang@qnx.com> wrote:

It is almost true > :slight_smile:
cOOl > :slight_smile:



For your filesystem sample, once on QNET, anybody could access
other nodes “/” or “/home” (they are in one big machine now),
but the usual file system permission still works, so, if you
are “smith”, on node A, you probably won’t be able to access
node B’s /home/joe.
So, as in unix, if the network has 2 (or more) same users, they’ll

be able to read private files.
You say “probably”… uhm, ok, let’s remove file permissions :wink:

Add some sort of access control in QNET (like never talk to “that
node”) is under consideration, but it is not in a high priority.
It’s definitively needed. The standard unix access control is still

more secure than that (and unix access control suxs! a lot! :slight_smile:)
I don’t need an ultra-secure system with ciphred filesystem, but
at LEAST the standard access control that unix has and
(this would be very usefull) the ability to exclude some paths
by name (/home/) or by permissions (for example I might decide to
exclude /home/ only if has 700 mode and so on…).
This would provide a more robust network, for every purpose.

Uhm, another question rises up: how I could get a list of all
known nodes without reading /net and resolving manually the
descriptors?

-xtang

–
John [ipv7.net]

4

john@broadcast.ipv7.net wrote:

Xiaodan Tang <> xtang@qnx.com> > wrote:

For your filesystem sample, once on QNET, anybody could access
other nodes “/” or “/home” (they are in one big machine now),
but the usual file system permission still works, so, if you
are “smith”, on node A, you probably won’t be able to access
node B’s /home/joe.
So, as in unix, if the network has 2 (or more) same users, they’ll
be able to read private files.
You say “probably”… uhm, ok, let’s remove file permissions > :wink:

Maybe I didn’t make it clear. The “normal unix security” is still
available cross QNET.

That is, a normal user can’t access other’s file. And, for example,
normal user can’t send signal to root process …

Add some sort of access control in QNET (like never talk to “that
node”) is under consideration, but it is not in a high priority.
It’s definitively needed. The standard unix access control is still
more secure than that (and unix access control suxs! a lot! > :slight_smile:> )
I don’t need an ultra-secure system with ciphred filesystem, but
at LEAST the standard access control that unix has and
(this would be very usefull) the ability to exclude some paths
by name (/home/) or by permissions (for example I might decide to
exclude /home/ only if has 700 mode and so on…).
This would provide a more robust network, for every purpose.

Uhm, another question rises up: how I could get a list of all
known nodes without reading /net and resolving manually the
descriptors?

I am not sure what you mean. There is “netmgr_ndtostr()” and
“netmgr_strtond()” to resolve a ND to a name, or name to ND.

All “known node” is under /net, so if you want to scan “known node”,
readdir("/net") is the only way.

-xtang

5

Xiaodan Tang <xtang@qnx.com> wrote:

john@broadcast.ipv7.net > wrote:
Xiaodan Tang <> xtang@qnx.com> > wrote:

For your filesystem sample, once on QNET, anybody could access
other nodes “/” or “/home” (they are in one big machine now),
but the usual file system permission still works, so, if you
are “smith”, on node A, you probably won’t be able to access
node B’s /home/joe.
So, as in unix, if the network has 2 (or more) same users, they’ll
be able to read private files.
You say “probably”… uhm, ok, let’s remove file permissions > :wink:

Maybe I didn’t make it clear. The “normal unix security” is still
available cross QNET.

That is, a normal user can’t access other’s file. And, for example,
normal user can’t send signal to root process …

One thing to look out for if you are trying to create a secure
LAN network that uses qnet, is that /etc/passwd, /etc/shadow, etc/groups,
and friends are by default kept locally on each node. Which means that
if Node A doesn’t have a root password (or the admin of node A is malicious)
then he has root privilages on all other nodes files. You could create symlinks
on those files to one box on the LAN so that they are all shared, but it’s easy
enough for a malicous user to reinstall QNX on their HD and get root access to
the entire LAN.

Personally I wouldn’t use QNET for generic LAN style file sharing unless
I was the only person using all the nodes (or it is a small group of people
that I trust using the network)
and I had a firewall up, otherwise I’d go with
the more traditional systems (like samba for example). It’s too much trouble
to administer otherwise.

However QNet is great for closed systems that have multiple “nodes”, or
systems that don’t require much security (don’t have the concept of “users”).

– drempel