Resource manager

bridged with qdn.public.qnxrtp.os
John Nagle

Re: Resource manager

Post by John Nagle » Wed Dec 24, 2003 6:45 am

Werner Schweizer wrote:
I'm trying to test my first resource manager.
On resmgr_attach() I get the error "Operation not permitted".
The manual states, that a resource manager has to be run as root
to be able to attach.
Well, started as root it works.

Why does it have this restriction?
IMHO it would be much more flexible,
if resmgr_attach() could respect the permissions
I'd argue that you should be able to take over a piece
of the pathname space if all the resource managers who
already own that namespace agree that it is OK.
An attempt to do a resmgr_attach should result in a
message going in turn to each resource manager with
existing authority over that namespace, as with
any other request. The resource manager should
answer "yes", "no", or "don't care" to the resmgr_attach
request, much like the way opens work.

Default policy for resource managers would be "no",
but resource managers that implement file systems that
allow making directories could say "yes" if their permission
rules permitted making a directory at that point.

There's a problem with program launch trusting
permissions information from a resource manager, but
that can be settled by having program launch check
whether the resource manager that owns the object being
launched is trusted.

The "root" restriction on resmgr_attach is bad for security;
it results in code running as root that doesn't really have to
run as root. Only drivers that need hardware access
should have to run as root.

The whole business of how processes get linked up needs some
rethinking. The resource-manager structure is oriented
towards I/O; if you want to use QNX messages as transactions,
it's a bad fit. name_attach is useful, but the documentation
says it's deprecated. name_open doesn't yet work across the network.
(Even without "global names", it should be possible to open
"/net/NODENAME/dev/name/local/CONNECTIONNAME" when appropriate,
but that doesn't work, I'm told.) And I've mentioned in other messages,
inter-node spawn is buggy.

The end result is that building a distributed real-time system
is a huge pain. Messaging works fine once you set up the connnections,
but setting them up is a mess.

John Nagle
Team Overbot

Bill Caroselli

Re: Resource manager

Post by Bill Caroselli » Wed Dec 24, 2003 2:16 pm

John Nagle <nagle@downside.com> wrote:

JN > The whole business of how processes get linked up needs some
JN > rethinking. The resource-manager structure is oriented
JN > towards I/O; if you want to use QNX messages as transactions,
JN > it's a bad fit. name_attach is useful, but the documentation
JN > says it's deprecated. name_open doesn't yet work across the network.
JN > (Even without "global names", it should be possible to open
JN > "/net/NODENAME/dev/name/local/CONNECTIONNAME" when appropriate,
JN > but that doesn't work, I'm told.) And I've mentioned in other messages,
JN > inter-node spawn is buggy.

JN > The end result is that building a distributed real-time system
JN > is a huge pain. Messaging works fine once you set up the connnections,
JN > but setting them up is a mess.

Hi John. I do completely agree with you. However . . .

If it is such a big deal to have a resource manager run as root, you
can write your own version of the QNX4 nameloc utility, and run it as
a root process. Then other non-root processes can easily name_attach(),
name_detach() and name_locate(). Then all of your transaction server
processes need not bother running as root. They can just register
themselves with the phone book.

In fact, I think that this is such a good idea that I'm going to
authorize QSSL to release the source to QNX4's nameloc. It will have
to be modified to return the channel in addiotion to the pid. QSSL can
also strip out the QNX4 licensing code if they want to.

Wojtek Lerch

Re: Resource manager

Post by Wojtek Lerch » Mon Dec 29, 2003 6:25 pm

Mario Charest <postmaster@127.0.0.1> wrote:
"Wojtek Lerch" <wojtek_l@yahoo.ca> wrote in message
news:brvh5b$mi1$1@nntp.qnx.com...
Any user with access to a compiler or to an ftp client can write or
download a resource manager that presents a setuid-root copy of /bin/sh
to the OS. The sys admin needs to be able to disallow untrusted users
to run such resource managers. Your proposed protection based on access
rigths on the parent directory doesn't solve this, does it?

It doesn't Wojtek, but I've been wondering if somehow resmgr could be
"force" to respect the parents permission. Situation comes from the
principle that resmgr are free to do what they want as far as returning
permission flags, and I wonder if it has to be that way.
I'm afraid it does: any resmgr that is expected to support chown() and
chmod() must be allowed to return any combination of user id and
permission bits that a sufficiently privileged client may decide to set
a file to.

The setuid root problem is just the most obvious security hole that
allowing untrusted resmgrs would open, but I'm sure there are many
others. For instance, there may be a legitimate setuid-root program
that saves some sensitive information to a temporary file. If the
program uses the O_EXCL flag and creates the file as unreadable to
anybody, the data should be safe; but only if the filesystem can be
trusted. If I manage to fool the program into saving its data to my own
resmgr, I can steal or alter information that I wasn't supposed to have
access to. Sounds much easier than finding and exploiting a buffer
overflow...

John Nagle

Re: Resource manager

Post by John Nagle » Sat Jan 03, 2004 4:24 am

Hi John. I do completely agree with you. However . . .

If it is such a big deal to have a resource manager run as root, you
can write your own version of the QNX4 nameloc utility, and run it as
a root process. Then other non-root processes can easily name_attach(),
name_detach() and name_locate(). Then all of your transaction server
processes need not bother running as root. They can just register
themselves with the phone book.
We essentially did something like that, but we did it by having
our programs all be children of our "watchdog", which knows which
process is which and can provide directory services.
In fact, I think that this is such a good idea that I'm going to
authorize QSSL to release the source to QNX4's nameloc. It will have
to be modified to return the channel in addiotion to the pid. QSSL can
also strip out the QNX4 licensing code if they want to.
That sounds like a step in the right direction.

John Nagle
Team Overbot

Werner Schweizer

Re: Resource manager

Post by Werner Schweizer » Mon Jan 05, 2004 9:14 am

Thanks for any responses.
It seems to be a complex problem.
This comes mainly from the fact, that some people is talking about general
purpose computer.
Others, like me, are talking about embedded systems,
where the security rules are completely different.
There is no general purpose MMI,
only application specific user interaction is possible.
Security problems have to be considered only for service access
via telnet or other remote access.

I'm planing to implement my whole application
(a newspaper mailroom automation system)
as a couple of processes programmed as resource managers.
It has to be done in a way, that in a small mailroom,
all processes are run on one PC.
In a large mailroom, the processes heve to be spread over a couple of PC's.
These RM's are not general purpose, but largely depending on each other
and to the hardware and equipment (machines produced by our company).

The current OS rules are forcing me to run the whole application as root.
A lot of the protection mechanisms the OS provides,
are inactive for root processes and have to be reimplemented by the RM's.

"Werner Schweizer" <nospamWrnr.Schwzr@ch.mullermartini.com> schrieb im
Newsbeitrag news:lu26b1-i14.ln1@dmzu001.gia.ch...
I'm trying to test my first resource manager.
On resmgr_attach() I get the error "Operation not permitted".
The manual states, that a resource manager has to be run as root
to be able to attach.
Well, started as root it works.

Why does it have this restriction?
IMHO it would be much more flexible,
if resmgr_attach() could respect the permissions
of the parent directory, where the new name is attached to.

I want to debug my resource managers
in a Neutrino based self hosted environement (Momentics PE 6.2.1b),
With this restriction I have to do it as root,
otherwise I'm not able to test my programms
directly from inside the IDE.

MfG
Werner Schweizer

Post Reply

Return to “qdn.public.qnxrtp.os”