SUID problems - Any Ideas

I have a configuration file on my FC1 epos system that I don't want the general 'epos' user to be able to write to - Hence its root:root 644 (rw - root - r to group and r to everyone else).

However I need an application which is run by the general user 'epos' to be able to write to the file - increment a report number counter.

The obvious solution it would seem to me was to chmod +s the application.

However, the application is written in kylix and needs a couple of environment variables to be set (LD_LIBRARY_PATH & LANG) to operate and so when the SUID report application is run it runs under the root user and doesn't have these ENV variables set.

I have tried chmod +s the shell script that sets these variabes, but it seems that you a SUID script doesn't actually run with SUID permissions - a simple example demonstartes this:

test.sh:

Code:

---

echo hello > test.file

---

chown root:root test.sh
chmod 755 test.sh
chmod +s test.sh
su - epos
./test.sh

and

ls -l test.file
shows ownership to epos

I've tried putting the ENV variabls into /etc/bashrc - which doesn't seem to work either.

Does anyone have any another suggestions?

Steve

Probably your best bet is to create a tiny, secure program (in C) which will JUST increment the counter, and do nothing else. Make that setuid. Every time you want to increment the counter, just run that.

You could create a user just to own the counter file, chown the file to the, and have the program setuid to that user (like "counter" or something). That way any vulnerability in the program would only allow a malicious user to update the counter, not do anything else.

The only issue there is a slight performance hit from having to execute a new process. But a small C program starts up pretty quickly.

Another option is to make the Kylix program work set-uid. Although you can't set LD_LIBRARY_PATH for setuid apps, you can add the library path for the Kylix libraries to /etc/ld.so.conf, and have it automatically searched - this will even work for setuid programs.

EDIT: Setting the LANG variable should work fine for setuid programs.

Linux does not support setuid scripts because of the historical security problems - with most interpreters (especially sh) it is impossible to write them securely.

If you're just after file permissions, you could consider using set-groupid instead of setuid, and create a group to own the file.

Slarty

Quote:

---

Originally posted here by slarty
Probably your best bet is to create a tiny, secure program (in C) which will JUST increment the counter, and do nothing else. Make that setuid. Every time you want to increment the counter, just run that.

You could create a user just to own the counter file, chown the file to the, and have the program setuid to that user (like "counter" or something). That way any vulnerability in the program would only allow a malicious user to update the counter, not do anything else.

The only issue there is a slight performance hit from having to execute a new process. But a small C program starts up pretty quickly.

---

This is the conclusion I was comming to - I just didn't want to go down this route. The file is a bit more than a counter and kylis has some good routines to work with conf files that I dodn't want to have to replicate in C but c'est la vie

Quote:

---

Another option is to make the Kylix program work set-uid. Although you can't set LD_LIBRARY_PATH for setuid apps, you can add the library path for the Kylix libraries to /etc/ld.so.conf, and have it automatically searched - this will even work for setuid programs.

---

Yeah I'be been down this path - ld.so.cond & ldconfig _but_ kylix uses some libraries that start bpl... and ldconfig ignores them - Bloody kylix is a pain! I wish we'd never chosen it now.

Quote:

---

EDIT: Setting the LANG variable should work fine for setuid programs.

---

Handy to know, I'll test.

Quote:

---

Linux does not support setuid scripts because of the historical security problems - with most interpreters (especially sh) it is impossible to write them securely.

---

I didn't know that, but once I thought about it it's fairly obvious...

i wonder if there is anything to covert a script to a binary?

Quote:

---

If you're just after file permissions, you could consider using set-groupid instead of setuid, and create a group to own the file.

Slarty

---

I may look at this if I can sort out the suid issue - then move to a setgid solution

Ok, another option:

Create a small C program, which you will make set-uid (or setgid if the file is group owned by a group with write access).

Have this program clear out the environment (except for a few common stuff like PATH and HOME etc), set the LD_LIBRARY_PATH, then exec the kylix program.

It might be necessary to do setuid(geteuid()) or something (ditto for group ID).

Clearing the environment is so that a malicious user with "epos" access can't gain access to this more privileged account (or group) by setting LD_PRELOAD and such like.

Mark

I've got a proggy that does the required work for me - reading & writing to the file, but how would I stop an epos user figuring out what it does & passing the correct parameters to fool around with things.

you need to pass it a password, but (& you would have to be really quick) ps aux would show the command line parameters passed.

I like the above idea - it's what I was trying to do with a shell script - Hmmmm.

Steve