Prev: Ubuntu on lowram
Next: System Noise - pulsing whir
From: Maxwell Lol on 3 Jun 2010 21:46 Aragorn <aragorn(a)chatfactory.invalid> writes: >> Within this script I need to write a comment to a log file. I'd prefer >> if this log file was only readable / modifyable by root alone. Is >> there a way to do this? > > Yes, you can set the script's SUID bit so that whoever runs it, runs it > with the privileges of the owner, i.e. root. Linux does not have the capability to have a secure SETUID script. Why not make it mode 722? Grant people write access to it, but not read. Put it in a directory with 711 permission so they can't rename it or see the size.
From: Maxwell Lol on 3 Jun 2010 21:56 Robert Riches <spamtrap42(a)verizon.net> writes: > Most *ix system disallow suid-root scripts, because there are too > many ways for those to cause security problems. One option would > be to write a very short C program that opens one file using an > absolute path/filename, copies up to 50 or 100 or whatever > characters from stdin to the file, then closes the file. Make > the binary suid-root and call it from the script. There are wrapper programs writting in C that can be used to safely execute a shell script. I've used one that comes with majordomo. I've seen other examples, and recommend a google search. Others have mentioned sudo. Perl also has a a mechanism to write setuid perl scripts. It keeps track of "tainted" data - data that comes from the outside. It will generate warnings if the tainted data is used without cleansing the contents (i.e. using a s/// on the data, etc.) But as I said, what about the simple: as root mkdir /newdir chmod 711 /newdir touch /newdir/testlog chmod 722 /newdir/testlog As normal user: echo "newdata" >>/newdir/testlog works, but cat /newdir/testlog causes: cat: /newdir/testlog: Permission denied
From: Denis McMahon on 5 Jun 2010 12:46 On 04/06/10 02:56, Maxwell Lol wrote: > Robert Riches <spamtrap42(a)verizon.net> writes: > >> Most *ix system disallow suid-root scripts, because there are too >> many ways for those to cause security problems. One option would >> be to write a very short C program that opens one file using an >> absolute path/filename, copies up to 50 or 100 or whatever >> characters from stdin to the file, then closes the file. Make >> the binary suid-root and call it from the script. > > There are wrapper programs writting in C that can be used to safely > execute a shell script. I've used one that comes with majordomo. > I've seen other examples, and recommend a google search. > Others have mentioned sudo. > > Perl also has a a mechanism to write setuid perl scripts. It keeps > track of "tainted" data - data that comes from the outside. It will > generate warnings if the tainted data is used without cleansing the > contents (i.e. using a s/// on the data, etc.) > > But as I said, what about the simple: > as root > mkdir /newdir > chmod 711 /newdir > touch /newdir/testlog > chmod 722 /newdir/testlog > > As normal user: > > echo "newdata" >>/newdir/testlog > works, but > cat /newdir/testlog > causes: > cat: /newdir/testlog: Permission denied will echo "haha sucker" >/newdir/testlog over-write the existing data in the log? Because that would imo be a slight[1] flaw in a logging system. Rgds Denis McMahon [1] for slight === <expletive> huge
From: Maxwell Lol on 5 Jun 2010 16:43 Denis McMahon <denis.m.f.mcmahon(a)googlemail.co.uk> writes: >> But as I said, what about the simple: >> as root >> mkdir /newdir >> chmod 711 /newdir >> touch /newdir/testlog >> chmod 722 /newdir/testlog >> >> As normal user: >> >> echo "newdata" >>/newdir/testlog >> works, but >> cat /newdir/testlog >> causes: >> cat: /newdir/testlog: Permission denied > > will > > echo "haha sucker" >/newdir/testlog > > over-write the existing data in the log? Yes. But if you always use a script, and the users aren't malicious, then this is fine. If you want a secure soultion, for accountability, etc, and expect some users to try to hide their actions, this is not a good solution.
From: Rahul on 6 Jun 2010 17:43
Maxwell Lol <nospam(a)com.invalid> wrote in news:8739x1w6qt.fsf(a)mythtv.grymoire.com: > Yes. But if you always use a script, and the users aren't malicious, > then this is fine. > > If you want a secure soultion, for accountability, etc, and expect > some users to try to hide their actions, this is not a good solution. > Thanks! The only secure solution seems a setuid and unfortunately C seems the only way to do that. Too bad that bash scripts aren't allowed to do a previlage escalation for the log writing part. I wonder why though? Is bash in some way less secure than C? -- Rahul |