Helge Hafting <[EMAIL PROTECTED]> writes:
> > problem: you can change the content of the file between the two !!
> > so you can have your script, running as root, executing whatever
> > you want !!
>
> So that's the problem with SUID scripts. Seems to me it could be
> solved by *not* closing the
Hello,
> So that's the problem with SUID scripts. Seems to me it could be solved by
> *not* closing the script file, just keep it open. Why can't that be done?
Because the first open is done by the kernel but the second by the shell.
> It can't be possible, or someone would surely have fixed i
[...]
> the executable (bash, whatever) opens the file
> it closes it
> it changes uid/gid to reflect suid status -> so it becames root or whatever
> it reopens it
> and executes it
>
> problem: you can change the content of the file between the two !!
> so you can have your script, running as r
On Sun, 6 Dec 1998, Jiri Baum wrote:
> > > 1) kernel opens the file, finds it suid
> > > 2) kernel executes the shell with that uid
> > > 3) shell opens the same filename
> ...
> > I think it's probably the kernel that does the open on step 3,
>
> No, it's the shell - it gets passed the filename.
Hello,
> > The way I remember it is:
> >
> > 1) kernel opens the file, finds it suid
> > 2) kernel executes the shell with that uid
> > 3) shell opens the same filename
...
> I think it's probably the kernel that does the open on step 3,
No, it's the shell - it gets passed the filename. If it wa
ething else for the suid script.
>
> Don't forget the user can copy / link a suid script into his home directory.
Ahh, link is the thing I was looking for. Otherwise, the person who made
the suid script would be responsible for the exploit, which wasn't making
sense to me. I thin
gt; and executes it
The way I remember it is:
1) kernel opens the file, finds it suid
2) kernel executes the shell with that uid
3) shell opens the same filename
If some fast file-moving is done between (1) and (3), one can substitute
something else for the suid script.
Don't forget the user can
On: 03 Dec 1998 12:58:14 -0600 john writes:
>
> Joey Hess writes:
>> Because shell scripts are supposidly very often full of securitry holes when
>> suid.
>
> There's a bit more to it. There is a race condition that would
> permit you to substitute a script of
Le 03-Dec-98, Joey Hess a pris ses électrons pour écrire:
> Brandon Mitchell wrote:
>> Dang, looks like you are right Joey, at least I can't get a counter
>> example working. I have been forced to write csh scripts on linux that
>> are run by suid programs because bash will drop it's privleges to
| From: dpk <[EMAIL PROTECTED]>
|
| On Thu, 3 Dec 1998, Pere Camps wrote:
|
| I want my users to be able to execute this script:
|#!/bin/bash
|/sbin/kbdrate -r 30 -d 250
|/etc/init.d/gpm stop
|/etc/init.d/gpm start
|
| A better/more secure way is to install the package
[EMAIL PROTECTED] wrote:
> There's a bit more to it. There is a race condition that would permit you
> to substitute a script of your choice for the suid script and have it run
> suid.
Oh yeah. I forgot about that. :-)
--
see shy jo
Joey Hess writes:
> Because shell scripts are supposidly very often full of securitry holes when
> suid.
There's a bit more to it. There is a race condition that would permit you
to substitute a script of your choice for the suid script and have it run
suid.
--
John Hasler
Brandon Mitchell wrote:
> Dang, looks like you are right Joey, at least I can't get a counter
> example working. I have been forced to write csh scripts on linux that
> are run by suid programs because bash will drop it's privleges to the
> real user id. So, at least is some aspects, bash is worse
On Thu, 3 Dec 1998, Pere Camps wrote:
> > I mean, "feature". I don't know of any other shells that do this.
>
> Doesn't bash have a setting to avoid this? I haven't RTFMd the
> manuals, but it would be a sensible set.
Possibly when compiling, but not after bash has been made. Although, a
Brandon,
> It's in bash (which is also sh on most linux systems), a pain in the a**,
> I mean, "feature". I don't know of any other shells that do this.
Doesn't bash have a setting to avoid this? I haven't RTFMd the
manuals, but it would be a sensible set.
> > Either that or install the
Ben,
> First off, chown'ing them root.root does not make them suid, that requires
> chmod 4xxx or 2xxx (the first is suid, the second is sgid).
When I wrote that I was suiding the file root.root i meant
rwsrwsr-x... root root ... and not someting like root.adm.
> strongly suggest you now
nd then I put a NOPASSWD: and I have the same behaviour as I
would get with a suid script!
Thanks a lot for your help.
Salutacions, Pere __oUltima Ratio Regum
2:343/108.91 - _`\<;_mailto:[EMAIL PROTECTED]
PGP key available --- (_)/ (_) http://casal.upc.es/~pere/
Gary,
> Scripts are not allowed to set UID, it's a security feature. I don't
> know where this occurs, but it's pretty low level, perhaps in the
> kernel itself or in the shell,
Ok. I dindn't know that. I thought they worked as another program.
I've added the script to the sudoe
On Thu, 3 Dec 1998, Joey Hess wrote:
> > It's in bash (which is also sh on most linux systems), a pain in the a**,
> > I mean, "feature". I don't know of any other shells that do this.
>
> No, it's in the kernel. Any executable that starts with "#!" does this,
> because the kernel is repsonsible
Brandon Mitchell wrote:
> > Scripts are not allowed to set UID, it's a security feature. I don't
> > know where this occurs, but it's pretty low level, perhaps in the
> > kernel itself or in the shell, and there's no getting around it. There
> > are just too many holes that allowing scripts to be
On 3 Dec 1998, Gary L. Hennigan wrote:
> Pere Camps <[EMAIL PROTECTED]> writes:
> | I want my users to be able to execute this script:
> | The problem is that these programs need root's privileges. I've
> | suid the script root:root but still the programs say I don't have he right
> |
On Thu, Dec 03, 1998 at 01:01:26PM +, Pere Camps wrote:
> Hi!
>
> I want my users to be able to execute this script:
>
> #!/bin/bash
> /sbin/kbdrate -r 30 -d 250
> /etc/init.d/gpm stop
> /etc/init.d/gpm start
>
> The problem is that these programs need root's privileges. I've
>
On Thu, 3 Dec 1998, Pere Camps wrote:
Hi!
I want my users to be able to execute this script:
#!/bin/bash
/sbin/kbdrate -r 30 -d 250
/etc/init.d/gpm stop
/etc/init.d/gpm start
The problem is that these programs need root's
privileges. I've suid the scr
Pere Camps <[EMAIL PROTECTED]> writes:
| Hi!
|
| I want my users to be able to execute this script:
|
| #!/bin/bash
| /sbin/kbdrate -r 30 -d 250
| /etc/init.d/gpm stop
| /etc/init.d/gpm start
|
| The problem is that these programs need root's privileges. I've
| suid the script root:
Hi!
I want my users to be able to execute this script:
#!/bin/bash
/sbin/kbdrate -r 30 -d 250
/etc/init.d/gpm stop
/etc/init.d/gpm start
The problem is that these programs need root's privileges. I've
suid the script root:root but still the programs say I don't have he right
per
Jon Kaare Hellan wrote:
> I would prefer not to have to be root to choose the default
> route. Embedding the commands to /sbin/route in a suid/guid C-program
> works. Is there another workaround?
Look at setuidexec. It is in the setuidmanager package.
--
John Hasler
[EMAIL PROTECTED] (John Hasle
On Mon, Oct 05, 1998 at 10:52:08AM +0200, Jon Kaare Hellan wrote:
> I've got ppp interfaces defined for the workplaces of me and my wife,
> and use a small script to switch the default route to the interface
> that needs to be active.
ok...sounds interesting...
> This works, but I have to be root
I've got ppp interfaces defined for the workplaces of me and my wife,
and use a small script to switch the default route to the interface
that needs to be active.
This works, but I have to be root. I've tried to make the script
suid/guid root, but get a SIOC error message from /sbin/route.
I
28 matches
Mail list logo
