From: Maxwell Lol on
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
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
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
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
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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Ubuntu on lowram
Next: System Noise - pulsing whir