Re: VI wrapper for SUDO? - another bad way ??
On Tue, Dec 04, 2001 at 08:44:34PM +0100, Gerfried Fuchs wrote: > You have a misinformation/misinterpretation there. It's not disabled, > it's simply not possible in the way scripts are run. They are passed to > the program that is given in it's first line, after the #! - or to the > current shell, if there is no such line. As *argument*. Of course it's possible. Solaris does it, for example. The security issues do require careful thought, though. > > Btw, why was this mailed to debian-security? I don't see anything > related to debian in that, some general linux (security) > mailinglist/newsgroup would suit better. Probably mismailed, intended for [EMAIL PROTECTED] Jules
Re: VI wrapper for SUDO? - another bad way ??
On Tue, Dec 04, 2001 at 08:44:34PM +0100, Gerfried Fuchs wrote: > You have a misinformation/misinterpretation there. It's not disabled, > it's simply not possible in the way scripts are run. They are passed to > the program that is given in it's first line, after the #! - or to the > current shell, if there is no such line. As *argument*. Of course it's possible. Solaris does it, for example. The security issues do require careful thought, though. > > Btw, why was this mailed to debian-security? I don't see anything > related to debian in that, some general linux (security) > mailinglist/newsgroup would suit better. Probably mismailed, intended for debian-security@lists Jules -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
* William R Ward <[EMAIL PROTECTED]> [2001.12.04 10:48:19-0800]: > Right; but assumin gone takes care of this kind of issue, is there > anything inherently unsafe about running shell scripts through sudo? > I understand that there are risks of race conditions with setuid shell > scripts, and so they are disabled on most Linux boxen. Is that also > an issue for sudo shell scripts? there are no security flaws that emerge from using sudo. that is, a shell script that is safe for root to run will be safe for sudo. you do have to worry about such things as shell escaping and other stuff which would allow a user to break out of the sudo restriction to get a shell. vi is a dangerous one because you can execute shell commands. if you sudo emacs then you might just as well sudo a shell. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] "the human brain is like an enormous fish -- it is flat and slimy and has gills through which it can see." -- monty python pgp1CNqLBngvW.pgp Description: PGP signature
Re: VI wrapper for SUDO? - another bad way ??
[EMAIL PROTECTED] (William R. Ward) writes: > It's been an option on traditional Unix systems for a long time. When > kernel runs the interpreter listed on the #! line, it does so with > suid/sgid access enabled. It's not really any more difficult than > launching binaries. However, there is an unavoidable security hole if you have any setuid #! scripts, at least, as they are traditionally implemented. If you adjust the semantics slightly, it can be fixed, but even then, it's not usually judged to be that important.
Re: VI wrapper for SUDO? - another bad way ??
* William R Ward <[EMAIL PROTECTED]> [2001.12.04 10:48:19-0800]: > Right; but assumin gone takes care of this kind of issue, is there > anything inherently unsafe about running shell scripts through sudo? > I understand that there are risks of race conditions with setuid shell > scripts, and so they are disabled on most Linux boxen. Is that also > an issue for sudo shell scripts? there are no security flaws that emerge from using sudo. that is, a shell script that is safe for root to run will be safe for sudo. you do have to worry about such things as shell escaping and other stuff which would allow a user to break out of the sudo restriction to get a shell. vi is a dangerous one because you can execute shell commands. if you sudo emacs then you might just as well sudo a shell. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck "the human brain is like an enormous fish -- it is flat and slimy and has gills through which it can see." -- monty python msg04628/pgp0.pgp Description: PGP signature
Re: VI wrapper for SUDO? - another bad way ??
Gerfried Fuchs writes: >* William R. Ward <[EMAIL PROTECTED]> [2001-12-04 11:56]: >> Because the thread originated there. > > I haven't seen it before here. Do you really mean ><[EMAIL PROTECTED]> and not ? >Those are two totally different things Maybe you have to resend >your message there to let it show up in the correct list. You have my >permission to send my messages there, too. For completeness. But >please add that I don't read so if >someone answers s/he should consider to Cc: me if it seems relevant. I accidentally sent it to @debian.org, and Colin Watson pointed that error out to me. I re-sent it to @lists.debian.org, which is where the thread belongs. Note that I removed the CC to [EMAIL PROTECTED] The similarity of those two aliases is very confusing. I am also on a number of perl.org's lists, and for that domain the correct address is @perl.org, not @lists.perl.org. I think I confused the two. >> The original idea was debian-related, in that I wanted to be able to >> have /etc/alternatives be consulted when deciding what editor to >> invoke. > > /etc/alternatives is readable by every user. If you want just to >decide there is no need to do this as root. If you want to participate in that part of the discussion I suggest you read the list archives for [EMAIL PROTECTED] --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Re: VI wrapper for SUDO? - another bad way ??
[EMAIL PROTECTED] (William R. Ward) writes: > Gerfried Fuchs writes: [setuid scripts] >> You have a misinformation/misinterpretation there. It's not disabled, >>it's simply not possible in the way scripts are run. > It's been an option on traditional Unix systems for a long time. It's perfectly possible to implement, but Linus chose not to do so for security reasons. So you were both right. It is disabled, from the point of view of intentional nonimplementation. -- Alan Shutko <[EMAIL PROTECTED]> - In a variety of flavors! Stay together, drag each other down.
Re: VI wrapper for SUDO? - another bad way ??
[EMAIL PROTECTED] (William R. Ward) writes: > It's been an option on traditional Unix systems for a long time. When > kernel runs the interpreter listed on the #! line, it does so with > suid/sgid access enabled. It's not really any more difficult than > launching binaries. However, there is an unavoidable security hole if you have any setuid #! scripts, at least, as they are traditionally implemented. If you adjust the semantics slightly, it can be fixed, but even then, it's not usually judged to be that important. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
Gerfried Fuchs writes: >* William R. Ward <[EMAIL PROTECTED]> [2001-12-04 11:56]: >> Because the thread originated there. > > I haven't seen it before here. Do you really mean ><[EMAIL PROTECTED]> and not <[EMAIL PROTECTED]>? >Those are two totally different things Maybe you have to resend >your message there to let it show up in the correct list. You have my >permission to send my messages there, too. For completeness. But >please add that I don't read <[EMAIL PROTECTED]> so if >someone answers s/he should consider to Cc: me if it seems relevant. I accidentally sent it to @debian.org, and Colin Watson pointed that error out to me. I re-sent it to @lists.debian.org, which is where the thread belongs. Note that I removed the CC to [EMAIL PROTECTED] The similarity of those two aliases is very confusing. I am also on a number of perl.org's lists, and for that domain the correct address is @perl.org, not @lists.perl.org. I think I confused the two. >> The original idea was debian-related, in that I wanted to be able to >> have /etc/alternatives be consulted when deciding what editor to >> invoke. > > /etc/alternatives is readable by every user. If you want just to >decide there is no need to do this as root. If you want to participate in that part of the discussion I suggest you read the list archives for [EMAIL PROTECTED] --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
[EMAIL PROTECTED] (William R. Ward) writes: > Gerfried Fuchs writes: [setuid scripts] >> You have a misinformation/misinterpretation there. It's not disabled, >>it's simply not possible in the way scripts are run. > It's been an option on traditional Unix systems for a long time. It's perfectly possible to implement, but Linus chose not to do so for security reasons. So you were both right. It is disabled, from the point of view of intentional nonimplementation. -- Alan Shutko <[EMAIL PROTECTED]> - In a variety of flavors! Stay together, drag each other down. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
* William R. Ward <[EMAIL PROTECTED]> [2001-12-04 11:56]: > Yes, it is difficult, but if one is conscientious enough about > checking all the environment variables and such it can be done. For oneliners, maybe. But even there it's hard. YMMV. I can find better things than trying to secure shell scripts. >>> I understand that there are risks of race conditions with setuid shell >>> scripts, and so they are disabled on most Linux boxen. >> >> You have a misinformation/misinterpretation there. It's not disabled, >>it's simply not possible in the way scripts are run. They are passed to >>the program that is given in it's first line, after the #! - or to the >>current shell, if there is no such line. As *argument*. >> >> If you think about it how should the suid/sgid bit from an argument be >>given over to the program which handles that file? There's no way other >>than using wrappers, like sudo. > > It's been an option on traditional Unix systems for a long time. Linux Is Not UniX. > When kernel runs the interpreter listed on the #! line, it does so > with suid/sgid access enabled. Yes, for the interpreter. Do you see the contradiction? It runs suid/sgid enabled for the interpreter but not for the argument that is handed to the interpreter. > It's the kernel, not the shell, that parses the #! line. I didn't say anything else > I'm not sure in what ways Linux may differ from traditional Unix on > this point, however. In the way that Linux Is Not UniX. And furthermore, it's of course not traditionally (which IMHO most of the times means old-fasioned). Linux goes it's own way. > A lot of things, like sendmail for a prominent example, may use group > accounts but still expect the files to be owned and writable only by > root. So? I still don't know what your virtual shell script is about to do. I still see no contradiction there. The files that are owned and writeable only by root for sendmail are usually those that are config files, right? >> Btw, why was this mailed to debian-security? I don't see anything >>related to debian in that, some general linux (security) >>mailinglist/newsgroup would suit better. > > Because the thread originated there. I haven't seen it before here. Do you really mean <[EMAIL PROTECTED]> and not ? Those are two totally different things Maybe you have to resend your message there to let it show up in the correct list. You have my permission to send my messages there, too. For completeness. But please add that I don't read so if someone answers s/he should consider to Cc: me if it seems relevant. > The original idea was debian-related, in that I wanted to be able to > have /etc/alternatives be consulted when deciding what editor to > invoke. /etc/alternatives is readable by every user. If you want just to decide there is no need to do this as root. HTH, Alfie -- installations anleitung für intelx86 richtig ? Angel`Eye: Kommt auf deinen Rechner an. Wenn du die Antwort nicht weiß, ist sie ja. -- #debian.de
Re: VI wrapper for SUDO? - another bad way ??
Gerfried Fuchs writes: >* William R Ward <[EMAIL PROTECTED]> [2001-12-03 00:50]: >> Right; but assuming one takes care of this kind of issue, is there >> anything inherently unsafe about running shell scripts through sudo? > > shell scripts usually call other programs - whose behavior could be >most of the time changed with env-variables. It's almost impossible to >think of all those things. Yes, it is difficult, but if one is conscientious enough about checking all the environment variables and such it can be done. >> I understand that there are risks of race conditions with setuid shell >> scripts, and so they are disabled on most Linux boxen. > > You have a misinformation/misinterpretation there. It's not disabled, >it's simply not possible in the way scripts are run. They are passed to >the program that is given in it's first line, after the #! - or to the >current shell, if there is no such line. As *argument*. > > If you think about it how should the suid/sgid bit from an argument be >given over to the program which handles that file? There's no way other >than using wrappers, like sudo. It's been an option on traditional Unix systems for a long time. When kernel runs the interpreter listed on the #! line, it does so with suid/sgid access enabled. It's not really any more difficult than launching binaries. It's the kernel, not the shell, that parses the #! line. I'm not sure in what ways Linux may differ from traditional Unix on this point, however. >> Is that also an issue for sudo shell scripts? > > You should give sudo access to a shell script only to those persons who >you trust. After all, think about it - is root really needed there? >Most parts don't really need root but can be done through group usages, >like most things in Debian works. That gives you another level of >abstraction/security. A lot of things, like sendmail for a prominent example, may use group accounts but still expect the files to be owned and writable only by root. > Btw, why was this mailed to debian-security? I don't see anything >related to debian in that, some general linux (security) >mailinglist/newsgroup would suit better. Because the thread originated there. The original idea was debian-related, in that I wanted to be able to have /etc/alternatives be consulted when deciding what editor to invoke. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Re: VI wrapper for SUDO? - another bad way ??
* William R. Ward <[EMAIL PROTECTED]> [2001-12-04 11:56]: > Yes, it is difficult, but if one is conscientious enough about > checking all the environment variables and such it can be done. For oneliners, maybe. But even there it's hard. YMMV. I can find better things than trying to secure shell scripts. >>> I understand that there are risks of race conditions with setuid shell >>> scripts, and so they are disabled on most Linux boxen. >> >> You have a misinformation/misinterpretation there. It's not disabled, >>it's simply not possible in the way scripts are run. They are passed to >>the program that is given in it's first line, after the #! - or to the >>current shell, if there is no such line. As *argument*. >> >> If you think about it how should the suid/sgid bit from an argument be >>given over to the program which handles that file? There's no way other >>than using wrappers, like sudo. > > It's been an option on traditional Unix systems for a long time. Linux Is Not UniX. > When kernel runs the interpreter listed on the #! line, it does so > with suid/sgid access enabled. Yes, for the interpreter. Do you see the contradiction? It runs suid/sgid enabled for the interpreter but not for the argument that is handed to the interpreter. > It's the kernel, not the shell, that parses the #! line. I didn't say anything else > I'm not sure in what ways Linux may differ from traditional Unix on > this point, however. In the way that Linux Is Not UniX. And furthermore, it's of course not traditionally (which IMHO most of the times means old-fasioned). Linux goes it's own way. > A lot of things, like sendmail for a prominent example, may use group > accounts but still expect the files to be owned and writable only by > root. So? I still don't know what your virtual shell script is about to do. I still see no contradiction there. The files that are owned and writeable only by root for sendmail are usually those that are config files, right? >> Btw, why was this mailed to debian-security? I don't see anything >>related to debian in that, some general linux (security) >>mailinglist/newsgroup would suit better. > > Because the thread originated there. I haven't seen it before here. Do you really mean <[EMAIL PROTECTED]> and not <[EMAIL PROTECTED]>? Those are two totally different things Maybe you have to resend your message there to let it show up in the correct list. You have my permission to send my messages there, too. For completeness. But please add that I don't read <[EMAIL PROTECTED]> so if someone answers s/he should consider to Cc: me if it seems relevant. > The original idea was debian-related, in that I wanted to be able to > have /etc/alternatives be consulted when deciding what editor to > invoke. /etc/alternatives is readable by every user. If you want just to decide there is no need to do this as root. HTH, Alfie -- installations anleitung für intelx86 richtig ? Angel`Eye: Kommt auf deinen Rechner an. Wenn du die Antwort nicht weiß, ist sie ja. -- #debian.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
martin f krafft <[EMAIL PROTECTED]> writes: > * William R. Ward <[EMAIL PROTECTED]> [2001.11.29 18:00:40-0800]: > > Question: Is it generally considered secure enough to sudo a bash > > script like your sucpaliases? Or should a C equivalent be written > > instead? > > no. especially not the quick'n'dirty version that alvin posted. i am > not criticizing, but there is an art to writing secure shell scripts. > i can't give you full details, but two things that you should *never* > forget is using absolute paths for binaries only. in addition, set > your PATH to the standard explicitly. [example snipped] Right; but assumin gone takes care of this kind of issue, is there anything inherently unsafe about running shell scripts through sudo? I understand that there are risks of race conditions with setuid shell scripts, and so they are disabled on most Linux boxen. Is that also an issue for sudo shell scripts? --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Re: VI wrapper for SUDO? - another bad way ??
Gerfried Fuchs writes: >* William R Ward <[EMAIL PROTECTED]> [2001-12-03 00:50]: >> Right; but assuming one takes care of this kind of issue, is there >> anything inherently unsafe about running shell scripts through sudo? > > shell scripts usually call other programs - whose behavior could be >most of the time changed with env-variables. It's almost impossible to >think of all those things. Yes, it is difficult, but if one is conscientious enough about checking all the environment variables and such it can be done. >> I understand that there are risks of race conditions with setuid shell >> scripts, and so they are disabled on most Linux boxen. > > You have a misinformation/misinterpretation there. It's not disabled, >it's simply not possible in the way scripts are run. They are passed to >the program that is given in it's first line, after the #! - or to the >current shell, if there is no such line. As *argument*. > > If you think about it how should the suid/sgid bit from an argument be >given over to the program which handles that file? There's no way other >than using wrappers, like sudo. It's been an option on traditional Unix systems for a long time. When kernel runs the interpreter listed on the #! line, it does so with suid/sgid access enabled. It's not really any more difficult than launching binaries. It's the kernel, not the shell, that parses the #! line. I'm not sure in what ways Linux may differ from traditional Unix on this point, however. >> Is that also an issue for sudo shell scripts? > > You should give sudo access to a shell script only to those persons who >you trust. After all, think about it - is root really needed there? >Most parts don't really need root but can be done through group usages, >like most things in Debian works. That gives you another level of >abstraction/security. A lot of things, like sendmail for a prominent example, may use group accounts but still expect the files to be owned and writable only by root. > Btw, why was this mailed to debian-security? I don't see anything >related to debian in that, some general linux (security) >mailinglist/newsgroup would suit better. Because the thread originated there. The original idea was debian-related, in that I wanted to be able to have /etc/alternatives be consulted when deciding what editor to invoke. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
martin f krafft <[EMAIL PROTECTED]> writes: > * William R. Ward <[EMAIL PROTECTED]> [2001.11.29 18:00:40-0800]: > > Question: Is it generally considered secure enough to sudo a bash > > script like your sucpaliases? Or should a C equivalent be written > > instead? > > no. especially not the quick'n'dirty version that alvin posted. i am > not criticizing, but there is an art to writing secure shell scripts. > i can't give you full details, but two things that you should *never* > forget is using absolute paths for binaries only. in addition, set > your PATH to the standard explicitly. [example snipped] Right; but assumin gone takes care of this kind of issue, is there anything inherently unsafe about running shell scripts through sudo? I understand that there are risks of race conditions with setuid shell scripts, and so they are disabled on most Linux boxen. Is that also an issue for sudo shell scripts? --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
* William R. Ward <[EMAIL PROTECTED]> [2001.11.29 18:00:40-0800]: > Question: Is it generally considered secure enough to sudo a bash > script like your sucpaliases? Or should a C equivalent be written > instead? no. especially not the quick'n'dirty version that alvin posted. i am not criticizing, but there is an art to writing secure shell scripts. i can't give you full details, but two things that you should *never* forget is using absolute paths for binaries only. in addition, set your PATH to the standard explicitly. in alvin's example, he does mv /tmp/aliases /etc/aliases within the script run as root via sudo. it would not be hard to make it take the script /tmp/mv that i have just provided instead of /bin/mv, because all that the script cares about is which mv executable if found first... -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] wind catches lily, scattering petals to the ground. segmentation fault. pgpPaGKUDHoD2.pgp Description: PGP signature
Re: VI wrapper for SUDO? - another bad way ??
* William R. Ward <[EMAIL PROTECTED]> [2001.11.29 18:00:40-0800]: > Question: Is it generally considered secure enough to sudo a bash > script like your sucpaliases? Or should a C equivalent be written > instead? no. especially not the quick'n'dirty version that alvin posted. i am not criticizing, but there is an art to writing secure shell scripts. i can't give you full details, but two things that you should *never* forget is using absolute paths for binaries only. in addition, set your PATH to the standard explicitly. in alvin's example, he does mv /tmp/aliases /etc/aliases within the script run as root via sudo. it would not be hard to make it take the script /tmp/mv that i have just provided instead of /bin/mv, because all that the script cares about is which mv executable if found first... -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck wind catches lily, scattering petals to the ground. segmentation fault. msg04562/pgp0.pgp Description: PGP signature
Re: VI wrapper for SUDO? - another bad way ??
Alvin Oga writes: >if that sh script is called sucpaliases... >you cannot(should not) put "sudo sucpaliases" inside of it > - infinite recursion... Of course not. The script I wrote is "editaliases" and inside that script, your "sucpaliases" is called. >-- another simpler way is to make /etc/aliases group writable > and newaliases for sudo by certain users > -- good and bad idea.. > >-- and you can put /etc/aliases into cvs control tooo These ideas are OK for some things, not for others. Sendmail is picky about the ownership and permissions on certain files. >-- c code is subject to buffer overflow problems... >-- scripts are susceptable to environment variables changing... Right - but I think the former is easier to thwart. Don't most Linux systems prohibit setuid shell scripts, for example? >-- in either case... you have to trust your users that run the > scripts/apps to replace /etc/aliases w/o giving um root access Of course, the idea is to give certain permissions to certain users without giving away the farm. That's what sudo's all about. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Re: VI wrapper for SUDO? - another bad way ??
Alvin Oga writes: >if that sh script is called sucpaliases... >you cannot(should not) put "sudo sucpaliases" inside of it > - infinite recursion... Of course not. The script I wrote is "editaliases" and inside that script, your "sucpaliases" is called. >-- another simpler way is to make /etc/aliases group writable > and newaliases for sudo by certain users > -- good and bad idea.. > >-- and you can put /etc/aliases into cvs control tooo These ideas are OK for some things, not for others. Sendmail is picky about the ownership and permissions on certain files. >-- c code is subject to buffer overflow problems... >-- scripts are susceptable to environment variables changing... Right - but I think the former is easier to thwart. Don't most Linux systems prohibit setuid shell scripts, for example? >-- in either case... you have to trust your users that run the > scripts/apps to replace /etc/aliases w/o giving um root access Of course, the idea is to give certain permissions to certain users without giving away the farm. That's what sudo's all about. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
hi ya bill if that sh script is called sucpaliases... you cannot(should not) put "sudo sucpaliases" inside of it - infinite recursion... the original idea was to copy and install the users versions of /etc/aliases file w/o giving um root or changing permissions... and not to allow sucpaliases to edit the file directly ( edit the file as a user ... -- another simpler way is to make /etc/aliases group writable and newaliases for sudo by certain users -- good and bad idea.. -- and you can put /etc/aliases into cvs control tooo -- c code is subject to buffer overflow problems... -- scripts are susceptable to environment variables changing... -- in either case... you have to trust your users that run the scripts/apps to replace /etc/aliases w/o giving um root access c ya alvin On Thu, 29 Nov 2001, William R. Ward wrote: > Alvin Oga writes: > >how about: ( maybe a dumb idea but...a temporary answer?? > > > >user> vi /etc/aliases > > - save it to /tmp/aliases > > > >user> sucpaliases > > > >where sucp: and allow users to run sucp as root > > - add sucpaliases into the sudo file > > Not bad... then wrap the whole thing in a script.. editaliases would > do the above steps > > #!/bin/sh > > tmpfile=/tmp/editaliases$$ > cp /etc/aliases $tmpfile > /etc/alternatives/editor $tmpfile > sudo sucpaliases $tmpfile > sudo newaliases # for good measure > # end editaliases > > Question: Is it generally considered secure enough to sudo a bash > script like your sucpaliases? Or should a C equivalent be written > instead? > > --Bill. >
Re: VI wrapper for SUDO? - another bad way ??
Alvin Oga writes: >how about: ( maybe a dumb idea but...a temporary answer?? > >user> vi /etc/aliases > - save it to /tmp/aliases > >user> sucpaliases > >where sucp: and allow users to run sucp as root > - add sucpaliases into the sudo file Not bad... then wrap the whole thing in a script.. editaliases would do the above steps #!/bin/sh tmpfile=/tmp/editaliases$$ cp /etc/aliases $tmpfile /etc/alternatives/editor $tmpfile sudo sucpaliases $tmpfile sudo newaliases # for good measure # end editaliases Question: Is it generally considered secure enough to sudo a bash script like your sucpaliases? Or should a C equivalent be written instead? --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Re: VI wrapper for SUDO? - another bad way ??
hi ya bill how about: ( maybe a dumb idea but...a temporary answer?? user> vi /etc/aliases - save it to /tmp/aliases user> sucpaliases where sucp: and allow users to run sucp as root - add sucpaliases into the sudo file #!/bin/bash # # sucpaliases # PATH=/sbin:/bin:/usr/sbin # # do some error checking too before executing these commands # mv /etc/aliases /etc/aliases.prev.xx mv /tmp/aliases /etc/aliases newaliases # # end of sucp c ya alvin On 29 Nov 2001, William R Ward wrote: > William R Ward <[EMAIL PROTECTED]> writes: > > Is there any kind of wrapper that can be used to allow sudo to grant > > editing access to only one file? I am thinking of something similar > > to vipw or visudo, but with security in mind; following this basic > > algorithm: > > > > 1. Using user privileges, Copy the desired file to a temp file owned > >by the real user. > > 2. Using user privileges, Edit the temp file. > > 3. Using root privileges, copy the temp file to the final location. >
Re: VI wrapper for SUDO? - another bad way ??
hi ya bill if that sh script is called sucpaliases... you cannot(should not) put "sudo sucpaliases" inside of it - infinite recursion... the original idea was to copy and install the users versions of /etc/aliases file w/o giving um root or changing permissions... and not to allow sucpaliases to edit the file directly ( edit the file as a user ... -- another simpler way is to make /etc/aliases group writable and newaliases for sudo by certain users -- good and bad idea.. -- and you can put /etc/aliases into cvs control tooo -- c code is subject to buffer overflow problems... -- scripts are susceptable to environment variables changing... -- in either case... you have to trust your users that run the scripts/apps to replace /etc/aliases w/o giving um root access c ya alvin On Thu, 29 Nov 2001, William R. Ward wrote: > Alvin Oga writes: > >how about: ( maybe a dumb idea but...a temporary answer?? > > > >user> vi /etc/aliases > > - save it to /tmp/aliases > > > >user> sucpaliases > > > >where sucp: and allow users to run sucp as root > > - add sucpaliases into the sudo file > > Not bad... then wrap the whole thing in a script.. editaliases would > do the above steps > > #!/bin/sh > > tmpfile=/tmp/editaliases$$ > cp /etc/aliases $tmpfile > /etc/alternatives/editor $tmpfile > sudo sucpaliases $tmpfile > sudo newaliases # for good measure > # end editaliases > > Question: Is it generally considered secure enough to sudo a bash > script like your sucpaliases? Or should a C equivalent be written > instead? > > --Bill. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
Alvin Oga writes: >how about: ( maybe a dumb idea but...a temporary answer?? > >user> vi /etc/aliases > - save it to /tmp/aliases > >user> sucpaliases > >where sucp: and allow users to run sucp as root > - add sucpaliases into the sudo file Not bad... then wrap the whole thing in a script.. editaliases would do the above steps #!/bin/sh tmpfile=/tmp/editaliases$$ cp /etc/aliases $tmpfile /etc/alternatives/editor $tmpfile sudo sucpaliases $tmpfile sudo newaliases # for good measure # end editaliases Question: Is it generally considered secure enough to sudo a bash script like your sucpaliases? Or should a C equivalent be written instead? --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
hi ya bill how about: ( maybe a dumb idea but...a temporary answer?? user> vi /etc/aliases - save it to /tmp/aliases user> sucpaliases where sucp: and allow users to run sucp as root - add sucpaliases into the sudo file #!/bin/bash # # sucpaliases # PATH=/sbin:/bin:/usr/sbin # # do some error checking too before executing these commands # mv /etc/aliases /etc/aliases.prev.xx mv /tmp/aliases /etc/aliases newaliases # # end of sucp c ya alvin On 29 Nov 2001, William R Ward wrote: > William R Ward <[EMAIL PROTECTED]> writes: > > Is there any kind of wrapper that can be used to allow sudo to grant > > editing access to only one file? I am thinking of something similar > > to vipw or visudo, but with security in mind; following this basic > > algorithm: > > > > 1. Using user privileges, Copy the desired file to a temp file owned > >by the real user. > > 2. Using user privileges, Edit the temp file. > > 3. Using root privileges, copy the temp file to the final location. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
