[NCLUG] Need to write to non-owned file

[Benson Chow]

The long explanation:

Programs like 'passwd' is basically doing what you want to do, except the 
target user is 'root'.  However, to do what you want to do, even though 
the target user is another non-privledged account, the pathway has been 
said and is the same as 'passwd' - switch to root first, then setuid to 
the target user (even this may not be necessary, just edit the file as 
root!).

The reason why this is "bad" is that it's not inherently bad - after all, 
it _is_ the only way to edit someone else's file when you have no 
permission otherwise (such as file/acl permissions).  The reason why it 
_is_ bad is that it's usually HARD to prevent the program to not 
"accidently" give any user of this program root privledges.

Let me tell you, given a naive implementation of a setuid program there 
are a lot of ways to crack into it and get root.  Everywhere from buffer 
overflows to timing attacks, you'll have to ensure every single method is 
blocked, from making sure all buffers are bounded and all file writes are 
atomic (with itself _and_ other programs), TO START WITH!  There's MUCH 
more to it than just these two examples!

If you trust your users as 'root' then by all means go for it!  It's 
actually very simple...  And 'setuid' is what you need to do.  But you 
might as well give everyone the root password.

BTW - even sudo solutions may not be secure, though 'sudoedit' as 
suggested has been attempted to be cleaned up of all potential privledge 
escalations much like the 'passwd' program.

Try hard to not need to go through this route if you don't trust your 
users with root access, else you'll have to go through a lot of auditing. 
Maybe you like to do the auditing.  It's _hard_ and it's the cause of why 
there are so many viruses floating around that exploit these bugs.

-bc

On Mon, 14 May 2007, bsimpson at att.net wrote:

>> The answer is that you don't actually want to do this. Really. It's
>> going to be a *huge* security hole.
>
> I'd like to understand why.
>
>> Consider the case where the user of your application tricks your program
>> into editing /etc/passwd or something like that.
>
> But /etc/passwd is owned by root.  Wouldn't you need root's password?
> And if you had root's password, you wouldn't need my application to
> wreak havoc on the system.
>
> I'd like to understand in general why this is a bad idea.
>
> I'll also mention that in this specific case it probably is a
> don't care.  The environment is a small satellite operations room
> where the machine is physically by the operator, and it is a closed
> environment - not connected to the Internet.  We screen our
> operators, since they would have more than just this opportunity
> to mess things up.
>
> The file to be written out is one of several configuration files.
> The engineers want a particular one not to be readily modifiable
> by the operators.
>
>> Equally, you probably don't want your program to read the user's
>> password and authenticate the user; it's a pain. It would require (at
>> least part of) your program running as root, calling a bunch of complex
>> APIs like setuid/seteuid/setgid/setegid, and probably a bunch of other
>> complex stuff.
>
> That may explain why I didn't see any examples of doing this in
> my limited search.  If, in general, it's a bad idea, I'd like to
> get a handle on why.
>
>> Instead, you're probably better off spawning a copy of su/sudo/login
>> (possibly within a spawned xterm etc. if it's a GUI app) and having that
>> prompt the user for the password, and running a command to write/edit
>> the file.
>
> That might be the way to go...

WARNING: All HTML emails get auto deleted.  DO NOT SEND HTML MAIL.
WARNING: Emails with large typo counts/spelling errors will also be deleted.