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,
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
* 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
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
[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
* 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
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
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
* 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
[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
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 debian-security@LISTS.debian.org?
Those are two totally different things Maybe you have to resend
[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
* 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
In message [EMAIL PROTECTED], Wichert Akkerman writes:
Previously Ted Cabeen wrote:
However, thinking about it, this doesn't work. If you're editing as root,
you
can use :e to switch to editing a SUID
Previously Ted Cabeen wrote:
However, thinking about it, this doesn't work. If you're editing as root, you
can use :e to switch to editing a SUID root file (any one you can write to
will work), delete the entire contents, and then use :r to bring in the
/bin/sh executable.
But you can
* 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,
Previously Ted Cabeen wrote:
However, thinking about it, this doesn't work. If you're editing as root, you
can use :e to switch to editing a SUID root file (any one you can write to
will work), delete the entire contents, and then use :r to bring in the
/bin/sh executable.
But you can
* 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,
hi,
maybe i misunderstand the intention here, but isn't it pointless to
restrict privileges of the editing process of /etc/aliases if you could
just as well change root's alias to a program that's run whenever root
receives email and, e. g., puts one's most favourite /etc/passwd in
place of the
That is a fair point but addressable with post-editing checks
in the wrapper. Of course, one is exceedingly vulnerable to
race conditions if one is not very careful about what is read and
when.
You don't have to use vi; there are dumber editors in the world.
Maybe you should just have some
hi joshua...
/etc/aliases... what can we do with it...
i dont know if this was bill's original intent or not
but lets see what can (regular) people do with /etc/aliases
/etc/aliases
badthing: mail -s send me the passwd [EMAIL PROTECTED] \
/etc/passwd
hi,
maybe i misunderstand the intention here, but isn't it pointless to
restrict privileges of the editing process of /etc/aliases if you could
just as well change root's alias to a program that's run whenever root
receives email and, e. g., puts one's most favourite /etc/passwd in
place of the
That is a fair point but addressable with post-editing checks
in the wrapper. Of course, one is exceedingly vulnerable to
race conditions if one is not very careful about what is read and
when.
You don't have to use vi; there are dumber editors in the world.
Maybe you should just have some
hi joshua...
/etc/aliases... what can we do with it...
i dont know if this was bill's original intent or not
but lets see what can (regular) people do with /etc/aliases
/etc/aliases
badthing: mail -s send me the passwd [EMAIL PROTECTED] \
/etc/passwd
A lazy sysadmin, not thinking through the ramifications, might put
things like /usr/bin/vi /etc/aliases in the sudoers file, thinking
that it limits access. But of course, vi has the :e command...
Is there any kind of wrapper that can be used to allow sudo to grant
editing access to only one
On Thu, Nov 29, 2001 at 02:45:08PM -0800, William R Ward wrote:
A lazy sysadmin, not thinking through the ramifications, might put
things like /usr/bin/vi /etc/aliases in the sudoers file, thinking
that it limits access. But of course, vi has the :e command...
Thats only if they arn't
On Thu, Nov 29, 2001 at 02:45:08PM -0800, William R Ward wrote:
A lazy sysadmin, not thinking through the ramifications, might put
things like /usr/bin/vi /etc/aliases in the sudoers file, thinking
that it limits access. But of course, vi has the :e command...
Searched groups.google.com for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
In message 20011129165355.A15543@ch208h, Mike Renfro writes:
A lazy sysadmin, not thinking through the ramifications, might put
things like /usr/bin/vi /etc/aliases in the sudoers file, thinking
that it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
In message [EMAIL PROTECTED], Ted Cabeen writes:
In message 20011129165355.A15543@ch208h, Mike Renfro writes:
A lazy sysadmin, not thinking through the ramifications, might put
things like /usr/bin/vi
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
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
#
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
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
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
A lazy sysadmin, not thinking through the ramifications, might put
things like /usr/bin/vi /etc/aliases in the sudoers file, thinking
that it limits access. But of course, vi has the :e command...
Is there any kind of wrapper that can be used to allow sudo to grant
editing access to only one
On Thu, Nov 29, 2001 at 02:45:08PM -0800, William R Ward wrote:
A lazy sysadmin, not thinking through the ramifications, might put
things like /usr/bin/vi /etc/aliases in the sudoers file, thinking
that it limits access. But of course, vi has the :e command...
Thats only if they arn't
On Thu, Nov 29, 2001 at 02:45:08PM -0800, William R Ward wrote:
A lazy sysadmin, not thinking through the ramifications, might put
things like /usr/bin/vi /etc/aliases in the sudoers file, thinking
that it limits access. But of course, vi has the :e command...
Searched groups.google.com for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
In message [EMAIL PROTECTED], Ted Cabeen writes:
In message [EMAIL PROTECTED], Mike Renfro writes:
A lazy sysadmin, not thinking through the ramifications, might put
things like /usr/bin/vi /etc/aliases in
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
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
#
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
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
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
43 matches
Mail list logo
