Prev: Ubuntu on lowram
Next: System Noise - pulsing whir
From: Chris F.A. Johnson on 6 Jun 2010 18:06
On 2010-06-06, Rahul wrote:
> 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?

Use sudo.

--
Chris F.A. Johnson, <http://cfajohnson.com>
Author:
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
From: The Natural Philosopher on 6 Jun 2010 18:56
Rahul wrote:
> 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?
>
yes.
From: Mumia W. on 6 Jun 2010 20:30
On 06/06/2010 04:43 PM, Rahul wrote:
> 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?
>

I think you have two good solutions:

1. Use syslog. It was made for this kind of thing.

2. Use group permissions, and let the script run as a special user (not
root) who is part of a group that has permission to write to the file.

From: Maxwell Lol on 6 Jun 2010 20:36
Rahul <nospam(a)nospam.invalid> writes:

> 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?

The real problem with set UID scripts is that the kernel has to do three steps:

1) Open the file, find the name of the engine (bash) and start the
engine.
2) Set the UID
3) Open the file read it into the engine.

Between 1 and 3, it is possible to change the contents of the script
file. While it seems hard, I can create a series of symbolic links
(hundreds) that point to the script. I then execute the setuid script,
and if I change one of the symbolic links, I can point to a new file
and gain priviledges.


Solaris allows setuid shell scripts. The Bourne shell has a special
flag that passes the contents of the script as a file descriptor,
instead of passing a file name.



First  |  Prev  | 
Pages: 1 2 3
Prev: Ubuntu on lowram
Next: System Noise - pulsing whir