Under QNX4, you can put setuid-root onto a script and it works.
Under QNX6, this doesn’t work. As I understand it, this is standard Unix
(POSIX) behaviour.
Fair enough, and I guess I can see the possible security implications, but
it is very inconvenient when trying to port/maintain systems that need to
run on both platforms and you have scripts that the user needs to be able to
run as root.
Does anyone have any good experience/workarounds for this? My initial
thought is to put “sudo” onto the target system and allow certain scripts to
be executed using sudo (via a wrapper script that just calls sudo on the
real script).
Any better ideas?
Rob Rutherford
Robert Rutherford <ruzz@nospamplease.ruzz.com> wrote:
Under QNX4, you can put setuid-root onto a script and it works.
Under QNX6, this doesn’t work. As I understand it, this is standard Unix
(POSIX) behaviour.
Fair enough, and I guess I can see the possible security implications, but
it is very inconvenient when trying to port/maintain systems that need to
run on both platforms and you have scripts that the user needs to be able to
run as root.
Does anyone have any good experience/workarounds for this? My initial
thought is to put “sudo” onto the target system and allow certain scripts to
be executed using sudo (via a wrapper script that just calls sudo on the
real script).
Any better ideas?
Copy ksh to, say sksh, and setuid on sksh. On script, do a
#!/bin/sksh
But anybody run sksh, they gain root access… 
-xtang
We use a small C program. It roughly does the following:
int main( int argc, char* argv[] )
{
setuid( geteuid() );
return system( argv[1] );
}
You still have to set the s-bit for the executable.
Regards
Peter
“Robert Rutherford” <ruzz@NoSpamPlease.ruzz.com> schrieb im Newsbeitrag
news:aonpkf$o00$1@inn.qnx.com…
Under QNX4, you can put setuid-root onto a script and it works.
Under QNX6, this doesn’t work. As I understand it, this is standard Unix
(POSIX) behaviour.
Fair enough, and I guess I can see the possible security implications, but
it is very inconvenient when trying to port/maintain systems that need to
run on both platforms and you have scripts that the user needs to be able
to
run as root.
Does anyone have any good experience/workarounds for this? My initial
thought is to put “sudo” onto the target system and allow certain scripts
to
be executed using sudo (via a wrapper script that just calls sudo on the
real script).
Any better ideas?
Rob Rutherford
“Peter Stockigt” <stoeckigt.p@stn-atlas.de> wrote:
We use a small C program. It roughly does the following:
int main( int argc, char* argv[] )
{
setuid( geteuid() );
return system( argv[1] );
}
That’s what /bin/on doing, it just don’t have the s-bit in
a clean install (secrutiy reason obverously).
-xtang
You still have to set the s-bit for the executable.
Regards
Peter
“Robert Rutherford” <> ruzz@NoSpamPlease.ruzz.com> > schrieb im Newsbeitrag
news:aonpkf$o00$> 1@inn.qnx.com> …
Under QNX4, you can put setuid-root onto a script and it works.
Under QNX6, this doesn’t work. As I understand it, this is standard Unix
(POSIX) behaviour.
Fair enough, and I guess I can see the possible security implications, but
it is very inconvenient when trying to port/maintain systems that need to
run on both platforms and you have scripts that the user needs to be able
to
run as root.
Does anyone have any good experience/workarounds for this? My initial
thought is to put “sudo” onto the target system and allow certain scripts
to
be executed using sudo (via a wrapper script that just calls sudo on the
real script).
Any better ideas?
Rob Rutherford
Both of the above responses have the problem of completely opening the
system up which I assume you don’t want to do. If you’re going to do the
wrapper script that Peter suggested, I would just make it a dedicated
program that only exists to call the script. ie.
int main( int argc, char* argv[] )
{
setuid( geteuid() );
return system( “/exact/path/to/my_hardwired_script.sh” );
}
The disadvantage is having to have one of these for each script but at least
it’s then secure. It’s simple enough that you could automate the production
of these wrappers by having a shell script during the make process which
substitutes the install name of the script into the code above, compiles it
and installs it with the script.
cheers,
Kris
“Robert Rutherford” <ruzz@NoSpamPlease.ruzz.com> wrote in message
news:aonpkf$o00$1@inn.qnx.com…
Under QNX4, you can put setuid-root onto a script and it works.
Under QNX6, this doesn’t work. As I understand it, this is standard Unix
(POSIX) behaviour.
Fair enough, and I guess I can see the possible security implications, but
it is very inconvenient when trying to port/maintain systems that need to
run on both platforms and you have scripts that the user needs to be able
to
run as root.
Does anyone have any good experience/workarounds for this? My initial
thought is to put “sudo” onto the target system and allow certain scripts
to
be executed using sudo (via a wrapper script that just calls sudo on the
real script).
Any better ideas?
Rob Rutherford
Kris Warkentin <kewarken@qnx.com> wrote:
: int main( int argc, char* argv[] )
: {
: setuid( geteuid() );
: return system( “/exact/path/to/my_hardwired_script.sh” );
: }
: The disadvantage is having to have one of these for each script but at least
: it’s then secure.
Can’t I then do this:
cp my_malicious_script /exact/path/to/my_hardwired_script.sh
if I have the appropriate permissions in /exact/path/to?
Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
Or just make a symlink of that hardcoded path point to whatever you want to
run.
\
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
Steve Reid <stever@qnx.com> wrote in message
news:aopr91$fjt$1@nntp.qnx.com…
Kris Warkentin <> kewarken@qnx.com> > wrote:
: int main( int argc, char* argv[] )
: {
: setuid( geteuid() );
: return system( “/exact/path/to/my_hardwired_script.sh” );
: }
: The disadvantage is having to have one of these for each script but at
least
: it’s then secure.
Can’t I then do this:
cp my_malicious_script /exact/path/to/my_hardwired_script.sh
if I have the appropriate permissions in /exact/path/to?
Steve Reid > stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
Adam Mallory <amallory@qnx.com> wrote:
Or just make a symlink of that hardcoded path point to whatever you want to
run.
Or start it in GDB and modify the memory location to point to whatever
script you want. 
Face it, setuid root is evil and if you do it you get what you ask for.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
I quite like Kris’s suggestion, especially the automated generation of the
wapper during the build process.
Both the ‘cp’ and ‘symlink’ issues can be circumvented by denying write
permission to the directory to which the hardcoded path points. The ‘gdb’
issue can be somewhat circumvented by not having gdb installed on the target
system.
However I’m not totally convinced that this is easier/better than using
sudo. sudo has some nice features (like logging).
I agree with Chris that having any setuid-root file in the system is a
potential problem, but in our case we are not trying to build Fort Knox,
rather we are just trying to ensure that the normal user runs in an
environment where they are protected from themselves (ie they can’t
accidentally rm -rf /) but they can still do what they need to do. And for
some things I just don’t see an alternative: like a user needing to start
(or re-start) a resource manager.
Thanks everyone for your suggestions.
Robert
“Chris McKillop” <cdm@qnx.com> wrote in message
news:aoqa0k$nbj$1@nntp.qnx.com…
Adam Mallory <> amallory@qnx.com> > wrote:
Or just make a symlink of that hardcoded path point to whatever you want
to
run.
Or start it in GDB and modify the memory location to point to whatever
script you want. >
Face it, setuid root is evil and if you do it you get what you ask for. >
chris
–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
We have to set our drivers to root to map physical memory and so created a
small program, ioset, to set stickey and root owner:
int main( int argc, char **argv )
{
int i;
int ecode = 0;
for( i = 1; i < argc; i++ )
{
if( chown( argv_, 0, 0) == -1 )
{
perror( argv );
ecode++;
}
//if( chmod( argv, S_ISVTX | S_IRUSR | S_IWUSR | S_IRGRP |
S_IROTH ) == -1 )
if( chmod( argv, 07775 ) == -1 )
{
perror( argv );
ecode++;
}
}
return ecode;
}
\
Jeffrey B. Holtz
Software Engineering
Electro Scientific Industries, Inc.
Ph: 734-332-7054
Fax: 734-332-7077
email: holtzj@esi.com
“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:aop3ee$1hi$1@nntp.qnx.com…_
“Peter Stockigt” <> stoeckigt.p@stn-atlas.de> > wrote:
We use a small C program. It roughly does the following:
int main( int argc, char* argv[] )
{
setuid( geteuid() );
return system( argv[1] );
}
That’s what /bin/on doing, it just don’t have the s-bit in
a clean install (secrutiy reason obverously).
-xtang
You still have to set the s-bit for the executable.
Regards
Peter
“Robert Rutherford” <> ruzz@NoSpamPlease.ruzz.com> > schrieb im Newsbeitrag
news:aonpkf$o00$> 1@inn.qnx.com> …
Under QNX4, you can put setuid-root onto a script and it works.
Under QNX6, this doesn’t work. As I understand it, this is standard
Unix
(POSIX) behaviour.
Fair enough, and I guess I can see the possible security implications,
but
it is very inconvenient when trying to port/maintain systems that need
to
run on both platforms and you have scripts that the user needs to be
able
to
run as root.
Does anyone have any good experience/workarounds for this? My initial
thought is to put “sudo” onto the target system and allow certain
scripts
to
be executed using sudo (via a wrapper script that just calls sudo on
the
real script).
Any better ideas?
Rob Rutherford
\