On Tue, Jul 17, 2001 at 04:17:23AM -0800, Ethan Benson wrote:
> On Tue, Jul 17, 2001 at 12:29:45PM +0100, Nick Phillips wrote:
> > On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote:
> >
> > > nice to know pam_pwdfile gained md5 support, iirc it only did the
> > > anchient crappy crypt b
On Tue, Jul 17, 2001 at 04:17:23AM -0800, Ethan Benson wrote:
> On Tue, Jul 17, 2001 at 12:29:45PM +0100, Nick Phillips wrote:
> > On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote:
> >
> > > nice to know pam_pwdfile gained md5 support, iirc it only did the
> > > anchient crappy crypt
On Tue, Jul 17, 2001 at 12:29:45PM +0100, Nick Phillips wrote:
> On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote:
>
> > nice to know pam_pwdfile gained md5 support, iirc it only did the
> > anchient crappy crypt before..
> >
> > now there just needs to be a passwd command to work wi
On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote:
> nice to know pam_pwdfile gained md5 support, iirc it only did the
> anchient crappy crypt before..
>
> now there just needs to be a passwd command to work with this...
htpasswd
--
Nick Phillips -- [EMAIL PROTECTED]
Don't feed t
On Tue, Jul 17, 2001 at 12:29:45PM +0100, Nick Phillips wrote:
> On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote:
>
> > nice to know pam_pwdfile gained md5 support, iirc it only did the
> > anchient crappy crypt before..
> >
> > now there just needs to be a passwd command to work w
On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote:
> nice to know pam_pwdfile gained md5 support, iirc it only did the
> anchient crappy crypt before..
>
> now there just needs to be a passwd command to work with this...
htpasswd
--
Nick Phillips -- [EMAIL PROTECTED]
Don't feed
On Tue, Jul 10, 2001 at 09:05:18AM -0400, Jason Healy wrote:
>
> At 994738826s since epoch (07/10/01 02:20:26 -0400 UTC), Micah Anderson wrote:
> > These both seem like excellent practices, for the clueless in all of us -
> > can someone describe how this is done for sudo? How do you configure PAM
On Tue, Jul 10, 2001 at 09:05:18AM -0400, Jason Healy wrote:
>
> At 994738826s since epoch (07/10/01 02:20:26 -0400 UTC), Micah Anderson wrote:
> > These both seem like excellent practices, for the clueless in all of us -
> > can someone describe how this is done for sudo? How do you configure PA
On Tue, Jul 10, 2001 at 09:05:18AM -0400, Jason Healy wrote:
> apt-get install libpam-doc libpam-opie libpam-pwdfile
>
> The first is docs, the second is OTP (one time passwords), and the
> third is to authenticate against "passwd-like" files. The idea with
> the third is that you make another pa
At 994738826s since epoch (07/10/01 02:20:26 -0400 UTC), Micah Anderson wrote:
> These both seem like excellent practices, for the clueless in all of us -
> can someone describe how this is done for sudo? How do you configure PAM to
> require alternative passwords, which expire and age, and are dec
At 994740997s since epoch (07/10/01 03:56:37 -0400 UTC), Ethan Benson wrote:
> detectability is the key here, the case should be locked shut ...
>
> compare this to your envolope idea where the machine need not even be
> shutdown and tell me which is more likely to go by unnoticed.
Okay, we've al
On Tue, Jul 10, 2001 at 09:05:18AM -0400, Jason Healy wrote:
> apt-get install libpam-doc libpam-opie libpam-pwdfile
>
> The first is docs, the second is OTP (one time passwords), and the
> third is to authenticate against "passwd-like" files. The idea with
> the third is that you make another p
At 994738826s since epoch (07/10/01 02:20:26 -0400 UTC), Micah Anderson wrote:
> These both seem like excellent practices, for the clueless in all of us -
> can someone describe how this is done for sudo? How do you configure PAM to
> require alternative passwords, which expire and age, and are de
At 994740997s since epoch (07/10/01 03:56:37 -0400 UTC), Ethan Benson wrote:
> detectability is the key here, the case should be locked shut ...
>
> compare this to your envolope idea where the machine need not even be
> shutdown and tell me which is more likely to go by unnoticed.
Okay, we've a
On Mon, Jul 09, 2001 at 08:38:56PM -0500, Martin Maney wrote:
>
> Give me physical access and I don't need your root password, though it may
> help make the job less detectable. But you don't get more security than you
> physically have to begin with.
detectability is the key here, the case shou
On Mon, 09 Jul 2001, Jason Healy wrote:
> About the best you can hope for is to log to another machine (so
> sudoers can't hose your logfiles), and be vigilant about checking what
> they do.
>
> Anyway, to your point about passwords, I say again (do we detect a
> theme?): use PAM and make them us
On Mon, Jul 09, 2001 at 08:38:56PM -0500, Martin Maney wrote:
>
> Give me physical access and I don't need your root password, though it may
> help make the job less detectable. But you don't get more security than you
> physically have to begin with.
detectability is the key here, the case sho
On Mon, 09 Jul 2001, Jason Healy wrote:
> About the best you can hope for is to log to another machine (so
> sudoers can't hose your logfiles), and be vigilant about checking what
> they do.
>
> Anyway, to your point about passwords, I say again (do we detect a
> theme?): use PAM and make them u
On Mon, Jul 09, 2001 at 04:18:10PM -0800, Ethan Benson wrote:
> On Mon, Jul 09, 2001 at 09:33:12AM -0400, Jason Healy wrote:
> > machine. The machine was locked in the server room, so the only
> > people who could get to the root password (and the console) were the
> > people with keys. If you ne
On Mon, Jul 09, 2001 at 09:33:12AM -0400, Jason Healy wrote:
>
> Our solution to this (multiple admins on a single box) was to write
> the root password (some horribly cryptic thing) down on a piece of
> paper and put it in a sealed envelope, which we then stuck to the
> machine. The machine was
from `man zsh`:
Alias expansion is done on the shell input before any
other expansion except history expansion. Therefore, if
an alias is defined for the word foo, alias expansion may
be avoided by quoting part of the word, e.g. \foo. But
there is no
On Mon, Jul 09, 2001 at 04:18:10PM -0800, Ethan Benson wrote:
> On Mon, Jul 09, 2001 at 09:33:12AM -0400, Jason Healy wrote:
> > machine. The machine was locked in the server room, so the only
> > people who could get to the root password (and the console) were the
> > people with keys. If you n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Jason" == Jason Healy <[EMAIL PROTECTED]> writes:
Jason> Our solution to this (multiple admins on a single box) was to
Jason> write the root password (some horribly cryptic thing) down on a
Jason> piece of paper and put it in a sealed envelope,
On Mon, Jul 09, 2001 at 09:33:12AM -0400, Jason Healy wrote:
>
> Our solution to this (multiple admins on a single box) was to write
> the root password (some horribly cryptic thing) down on a piece of
> paper and put it in a sealed envelope, which we then stuck to the
> machine. The machine was
<[EMAIL PROTECTED]> writes:
> On Mon, Jul 09, 2001 at 08:23:43PM +0100, Tim Haynes wrote:
>
> > Note that
> > alias '\/bin/su'="echo eek"
> >
> > comments accordingly on one's ability to bypass *that*, too.
> >
> > Woops. :)
>
> Have you tried it? :-) At least with my version of bash
from `man zsh`:
Alias expansion is done on the shell input before any
other expansion except history expansion. Therefore, if
an alias is defined for the word foo, alias expansion may
be avoided by quoting part of the word, e.g. \foo. But
there is n
On Mon, Jul 09, 2001 at 08:23:43PM +0100, Tim Haynes wrote:
> Note that
> alias '\/bin/su'="echo eek"
>
> comments accordingly on one's ability to bypass *that*, too.
>
> Woops. :)
Have you tried it? :-) At least with my version of bash (2.05.0(1)-release)
it won't do it. Or rather it'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Jason" == Jason Healy <[EMAIL PROTECTED]> writes:
Jason> Our solution to this (multiple admins on a single box) was to
Jason> write the root password (some horribly cryptic thing) down on a
Jason> piece of paper and put it in a sealed envelope
<[EMAIL PROTECTED]> writes:
> > > alias /bin/su='/var/tmp/hax0rSu'
> >
> > i would consider this a bug in the shell.
>
> Note that \/bin/su would avoid the alias.
Note that
alias '\/bin/su'="echo eek"
comments accordingly on one's ability to bypass *that*, too.
Woops. :)
~Tim
-
<[EMAIL PROTECTED]> writes:
> On Mon, Jul 09, 2001 at 08:23:43PM +0100, Tim Haynes wrote:
>
> > Note that
> > alias '\/bin/su'="echo eek"
> >
> > comments accordingly on one's ability to bypass *that*, too.
> >
> > Woops. :)
>
> Have you tried it? :-) At least with my version of bash
On Sat, Jul 07, 2001 at 03:16:39AM -0800, Ethan Benson wrote:
> On Sat, Jul 07, 2001 at 10:31:56AM +, Jim Breton wrote:
> > On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote:
> > > which may not work if you always type the
> > > full path to /bin/su anyway.
> >
> > Hoping he doesn
On Mon, Jul 09, 2001 at 08:23:43PM +0100, Tim Haynes wrote:
> Note that
> alias '\/bin/su'="echo eek"
>
> comments accordingly on one's ability to bypass *that*, too.
>
> Woops. :)
Have you tried it? :-) At least with my version of bash (2.05.0(1)-release)
it won't do it. Or rather it
<[EMAIL PROTECTED]> writes:
> > > alias /bin/su='/var/tmp/hax0rSu'
> >
> > i would consider this a bug in the shell.
>
> Note that \/bin/su would avoid the alias.
Note that
alias '\/bin/su'="echo eek"
comments accordingly on one's ability to bypass *that*, too.
Woops. :)
~Tim
On Sat, Jul 07, 2001 at 03:16:39AM -0800, Ethan Benson wrote:
> On Sat, Jul 07, 2001 at 10:31:56AM +, Jim Breton wrote:
> > On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote:
> > > which may not work if you always type the
> > > full path to /bin/su anyway.
> >
> > Hoping he does
ns, this is the same whether
or not you're using a shared root account, or sudo. If the admin is
ssh'ing in from home, on a compromised windows box, and using any type
of root function, the attacker now has the capability to do the same.
If you're worried about this sort of th
At 994683614s since epoch (07/09/01 11:00:14 -0400 UTC), Micah Anderson wrote:
> Having said that we do it this way as well, I'll point out one flaw which
> particularly nags at me. Andreas said, "a) allowing convenience by allowing
> the user to effectively choose their own root passwd." which rou
I agree with this assessment of Andreas' - in fact this is what we use in
our organization. Unfortunately we don't have the luxury of fully trusting
admins, so I am a little paranoid about giving out full-on sudo to people,
but this is mostly a personnel issue having to do with the nature of the
in
At 994696370s since epoch (07/09/01 04:32:50 -0400 UTC), Juha J?ykk? wrote:
> One question raises however: If I have multiple uid=0 accounts,
> will any of their passwords suffice as "root" password when entering
> single user mode? Obviously sudo will not do here, so I will need a
> root password,
ns, this is the same whether
or not you're using a shared root account, or sudo. If the admin is
ssh'ing in from home, on a compromised windows box, and using any type
of root function, the attacker now has the capability to do the same.
If you're worried about this sort of th
At 994683614s since epoch (07/09/01 11:00:14 -0400 UTC), Micah Anderson wrote:
> Having said that we do it this way as well, I'll point out one flaw which
> particularly nags at me. Andreas said, "a) allowing convenience by allowing
> the user to effectively choose their own root passwd." which ro
I agree with this assessment of Andreas' - in fact this is what we use in
our organization. Unfortunately we don't have the luxury of fully trusting
admins, so I am a little paranoid about giving out full-on sudo to people,
but this is mostly a personnel issue having to do with the nature of the
i
At 994696370s since epoch (07/09/01 04:32:50 -0400 UTC), Juha J?ykk? wrote:
> One question raises however: If I have multiple uid=0 accounts,
> will any of their passwords suffice as "root" password when entering
> single user mode? Obviously sudo will not do here, so I will need a
> root password
Nice little storm of a chain I managed to start here... Quite off
the original topic, mainly, where I trust the users. Many good points
have been noted and basically all of them have been argued both pro and
con. I will do a little summary here:
1) Some people like sudo, some think it is not s
Nice little storm of a chain I managed to start here... Quite off
the original topic, mainly, where I trust the users. Many good points
have been noted and basically all of them have been argued both pro and
con. I will do a little summary here:
1) Some people like sudo, some think it is not
This is completely off-topic at this point, but there are a few uses
of sudo. The original poster trusts his admins, and wants to give
them all root privs without the hassle of having them all use one
account. Sudo is not enforcing anything in this case, it is merely
a) allowing convenience by al
- Original Message -
From: "Robert L. Yelvington" <[EMAIL PROTECTED]>
To:
Sent: Friday, July 06, 2001 12:29 PM
Subject: Re: shared root account
> what's to stop a person, once they've sudo'd, from editing
/etc/sudoers and
> giving themselves more
This is completely off-topic at this point, but there are a few uses
of sudo. The original poster trusts his admins, and wants to give
them all root privs without the hassle of having them all use one
account. Sudo is not enforcing anything in this case, it is merely
a) allowing convenience by a
- Original Message -
From: "Robert L. Yelvington" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 06, 2001 12:29 PM
Subject: Re: shared root account
> what's to stop a person, once they've sudo'd, from editing
/etc/sudoers and
&g
Eric E Moore <[EMAIL PROTECTED]> writes:
> Ok, the amount of aiming away from your foot that you can do with
> giving someone priveleges by giving them the root password is a proper
> subset of the aiming away from your foot that you can do when
> granting priveleges through sudo.
Think of a daemo
> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes:
Ethan> On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote:
>> I would be very shocked if you could compromise a system with a
>> sudoers entry of: me hostname = (root) /bin/cat
Ethan> i would not, being able to read every file on
Eric E Moore <[EMAIL PROTECTED]> writes:
> Ok, the amount of aiming away from your foot that you can do with
> giving someone priveleges by giving them the root password is a proper
> subset of the aiming away from your foot that you can do when
> granting priveleges through sudo.
Think of a daem
> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes:
Ethan> On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote:
>> I would be very shocked if you could compromise a system with a
>> sudoers entry of: me hostname = (root) /bin/cat
Ethan> i would not, being able to read every file o
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha J?ykk? wrote:
> I have a bit of a situation: I have a handful of linux machines
> (almost all with different distributions and kernels and software -
> one hell to keep secure) and all the machines have different roots.
> These guys want to keep thei
On Sat, Jul 07, 2001 at 03:16:39AM -0800, Ethan Benson wrote:
> > alias /bin/su='/var/tmp/hax0rSu'
>
> i would consider this a bug in the shell.
I disagree; from the Bash man page:
The alias name and the replacement text may con-
tain any valid shell input, including the metac
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha J?ykk? wrote:
> I have a bit of a situation: I have a handful of linux machines
> (almost all with different distributions and kernels and software -
> one hell to keep secure) and all the machines have different roots.
> These guys want to keep the
On Sat, Jul 07, 2001 at 03:16:39AM -0800, Ethan Benson wrote:
> > alias /bin/su='/var/tmp/hax0rSu'
>
> i would consider this a bug in the shell.
I disagree; from the Bash man page:
The alias name and the replacement text may con-
tain any valid shell input, including the meta
[]
> yup, which is why nobody gets root but me. if i ever for some reason
> decided to go back to sysadmin work a criteria for employment would be
> that no manager, sales guy, or other morons would be permitted access
> to root for ANY REASON, period, end of story.
>
> as for sudo for my o
[]
> yup, which is why nobody gets root but me. if i ever for some reason
> decided to go back to sysadmin work a criteria for employment would be
> that no manager, sales guy, or other morons would be permitted access
> to root for ANY REASON, period, end of story.
>
> as for sudo for my
On Sat, Jul 07, 2001 at 10:31:56AM +, Jim Breton wrote:
> On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote:
> > which may not work if you always type the
> > full path to /bin/su anyway.
>
> Hoping he doesn't:
>
> alias /bin/su='/var/tmp/hax0rSu'
i would consider this a bug in
On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote:
> which may not work if you always type the
> full path to /bin/su anyway.
Hoping he doesn't:
alias /bin/su='/var/tmp/hax0rSu'
On Fri, Jul 06, 2001 at 10:24:28PM -0500, Nathan E Norman wrote:
>
> Depends on how you use it.
>
> At my last job, we used sudo for two reasons:
>
> 1) I didn't have to inform all the admins whenever the root password
> changed.
which is bogus since changing the root password means changing ea
On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote:
> I would be very shocked if you could compromise a system with a
> sudoers entry of:
> me hostname = (root) /bin/cat
i would not, being able to read every file on the system, even if you
can't write is going to lead to compromise soone
On Sat, Jul 07, 2001 at 02:54:27AM +0200, Simon Huggins wrote:
>
> Any user account that has access to the administrative account if
> compromised can give the attacker the admin account etc.
> sudo here is no worse than having your account compromised, your keys
> sniffed and su really.
the diff
On Fri, Jul 06, 2001 at 05:45:52PM -0700, Vineet Kumar wrote:
> You make a good point, even if one of your examples is flawed:
>
> $ sudo 'cat s >> /etc/sudoers'
> sudo: cat s >> /etc/sudoers: command not found
er yeah that quoting is bogus, im pretty sure you can do that command
in sudo if you p
On Sat, Jul 07, 2001 at 10:31:56AM +, Jim Breton wrote:
> On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote:
> > which may not work if you always type the
> > full path to /bin/su anyway.
>
> Hoping he doesn't:
>
> alias /bin/su='/var/tmp/hax0rSu'
i would consider this a bug in
On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote:
> which may not work if you always type the
> full path to /bin/su anyway.
Hoping he doesn't:
alias /bin/su='/var/tmp/hax0rSu'
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAI
On Fri, Jul 06, 2001 at 10:24:28PM -0500, Nathan E Norman wrote:
>
> Depends on how you use it.
>
> At my last job, we used sudo for two reasons:
>
> 1) I didn't have to inform all the admins whenever the root password
> changed.
which is bogus since changing the root password means changing e
On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote:
> I would be very shocked if you could compromise a system with a
> sudoers entry of:
> me hostname = (root) /bin/cat
i would not, being able to read every file on the system, even if you
can't write is going to lead to compromise soon
On Sat, Jul 07, 2001 at 02:54:27AM +0200, Simon Huggins wrote:
>
> Any user account that has access to the administrative account if
> compromised can give the attacker the admin account etc.
> sudo here is no worse than having your account compromised, your keys
> sniffed and su really.
the dif
On Fri, Jul 06, 2001 at 05:45:52PM -0700, Vineet Kumar wrote:
> You make a good point, even if one of your examples is flawed:
>
> $ sudo 'cat s >> /etc/sudoers'
> sudo: cat s >> /etc/sudoers: command not found
er yeah that quoting is bogus, im pretty sure you can do that command
in sudo if you
On Sat, Jul 07, 2001 at 12:11:44AM -0600, Will Aoki wrote:
> On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote:
> [cut]
> > I would be very shocked if you could compromise a system with a
> > sudoers entry of:
> > me hostname = (root) /bin/cat
>
> Depends on what's on the system. I've t
On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote:
[cut]
> I would be very shocked if you could compromise a system with a
> sudoers entry of:
> me hostname = (root) /bin/cat
Depends on what's on the system. I've thought of four similar ways.
1:
With Kerberos, you can steal someone's
On Fri, 06 Jul 2001, Juha J?ykk? <[EMAIL PROTECTED]> wrote...
: > > (Put the public key in the .authorized_keys file for the root user)
: > > TUrn on RSA/DSA authentication and 'allow root login'
: > One word of warning aboce would allow logging in using root password as
well
:
: I distrust a
On Sat, Jul 07, 2001 at 12:11:44AM -0600, Will Aoki wrote:
> On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote:
> [cut]
> > I would be very shocked if you could compromise a system with a
> > sudoers entry of:
> > me hostname = (root) /bin/cat
>
> Depends on what's on the system. I've
On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote:
[cut]
> I would be very shocked if you could compromise a system with a
> sudoers entry of:
> me hostname = (root) /bin/cat
Depends on what's on the system. I've thought of four similar ways.
1:
With Kerberos, you can steal someone'
On Fri, 06 Jul 2001, Juha J?ykk? <[EMAIL PROTECTED]> wrote...
: > > (Put the public key in the .authorized_keys file for the root user)
: > > TUrn on RSA/DSA authentication and 'allow root login'
: > One word of warning aboce would allow logging in using root password as well
:
: I distrust a
On Fri, Jul 06, 2001 at 03:24:56PM -0800, Ethan Benson wrote:
> On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote:
> >
> > OTOH if you restrict the user to a list of commands in /etc/sudoers,
> > it's wise to consider whether the user might be able to leverage one of
> > those comman
> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes:
Ethan> or even seemingly innocuous things like less or even cat.
Less is a problem, yes, as is anything else with a shell escape.
Ethan> sudo less anything !/bin/sh whoami r00t!
Ethan> echo me ALL=ALL > s sudo 'cat s >> /etc/sudoers'
do
On Fri, Jul 06, 2001 at 03:24:56PM -0800, Ethan Benson wrote:
> On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote:
> >
> > OTOH if you restrict the user to a list of commands in /etc/sudoers,
> > it's wise to consider whether the user might be able to leverage one of
> > those comma
On Fri, Jul 06, 2001 at 06:15:43AM -0800, Ethan Benson wrote:
> the main reason i don't use sudo except for small things which cannot
> grant a root shell in any way is for the simple reason the sudo
> converts a normal unprivleged user password into another root
> password.
Any user account tha
You make a good point, even if one of your examples is flawed:
$ sudo 'cat s >> /etc/sudoers'
sudo: cat s >> /etc/sudoers: command not found
sudo is a very useful tool in the type of situation described in this
thread. Even if you give everyone ALL=(ALL) ALL, it's better than su
or even .ssh/auth
On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote:
>
> OTOH if you restrict the user to a list of commands in /etc/sudoers,
> it's wise to consider whether the user might be able to leverage one of
> those commands to edit /etc/sudoers (or any other file). If you're
> going to list
> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes:
Ethan> or even seemingly innocuous things like less or even cat.
Less is a problem, yes, as is anything else with a shell escape.
Ethan> sudo less anything !/bin/sh whoami r00t!
Ethan> echo me ALL=ALL > s sudo 'cat s >> /etc/sudoers'
d
On Fri, Jul 06, 2001 at 06:15:43AM -0800, Ethan Benson wrote:
> the main reason i don't use sudo except for small things which cannot
> grant a root shell in any way is for the simple reason the sudo
> converts a normal unprivleged user password into another root
> password.
Any user account th
You make a good point, even if one of your examples is flawed:
$ sudo 'cat s >> /etc/sudoers'
sudo: cat s >> /etc/sudoers: command not found
sudo is a very useful tool in the type of situation described in this
thread. Even if you give everyone ALL=(ALL) ALL, it's better than su
or even .ssh/aut
On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote:
>
> OTOH if you restrict the user to a list of commands in /etc/sudoers,
> it's wise to consider whether the user might be able to leverage one of
> those commands to edit /etc/sudoers (or any other file). If you're
> going to list
At 994418143s since epoch (07/06/01 10:15:43 -0400 UTC), Ethan Benson wrote:
> On Fri, Jul 06, 2001 at 09:18:18AM -0400, Jason Healy wrote:
> > types of
> > passwords accepted to run root commands, etc).
>
> elaborate.
>
> the main reason i don't use sudo except for small things which cannot
> gr
Juha Jäykkä <[EMAIL PROTECTED]> writes:
> Any other ideas? Or is it really safe to allow root logins to sshd?
> It is just an old rule of thumb that root must never log on over the
> wire but that may be old news from times of telnet - never had any
> need of root logins over the wire until perh
At 994418143s since epoch (07/06/01 10:15:43 -0400 UTC), Ethan Benson wrote:
> On Fri, Jul 06, 2001 at 09:18:18AM -0400, Jason Healy wrote:
> > types of
> > passwords accepted to run root commands, etc).
>
> elaborate.
>
> the main reason i don't use sudo except for small things which cannot
> g
Juha Jäykkä <[EMAIL PROTECTED]> writes:
> Any other ideas? Or is it really safe to allow root logins to sshd?
> It is just an old rule of thumb that root must never log on over the
> wire but that may be old news from times of telnet - never had any
> need of root logins over the wire until per
On Fri, Jul 06, 2001 at 09:29:54AM -0700, Robert L. Yelvington wrote:
> admittedly, i am not very familiar with sudo because i have never seen the
> practical advantages of making su'ing more of a hassle by having to manage
> another set of conf files and keeping track of who's a sudoer and,
> ther
"Robert L. Yelvington" <[EMAIL PROTECTED]> writes:
> what's to stop a person, once they've sudo'd, from editing /etc/sudoers and
> giving themselves more privs?
sudo is to stop them, perhaps?
~Tim
--
15:40:15 up 9 days, 23:50, 12 users, load average: 0.19, 0.04, 0.01
[EMAIL PROTECTED] |The
admittedly, i am not very familiar with sudo because i have never seen the
practical advantages of making su'ing more of a hassle by having to manage
another set of conf files and keeping track of who's a sudoer and,
therefore, have chosen not to use it.
what's to stop a person, once they've sudo'
On Fri, Jul 06, 2001 at 09:18:18AM -0400, Jason Healy wrote:
> types of
> passwords accepted to run root commands, etc).
elaborate.
the main reason i don't use sudo except for small things which cannot
grant a root shell in any way is for the simple reason the sudo
converts a normal unprivleged u
On 06-Jul-01, 05:34 (CDT), Patrice Neff <[EMAIL PROTECTED]> wrote:
> What you want to accomplish might be possible with sudo. Install sudo
> and thenn add the following line to the configuration
> file. (/etc/sudoers on my machine)
> ALL=(ALL) ALL
>
> this will allow you to execute any c
At 994443564s since epoch (07/06/01 06:19:24 -0400 UTC), Juha J?ykk? wrote:
> I distrust allowing root logins from anywhere but local console(s)
> or non-modem gettys i.e. from anywhere over the not-owned-by-me cable.
> Any other ideas? Or is it really safe to allow root logins to sshd?
> It is
On Fri, Jul 06, 2001 at 09:29:54AM -0700, Robert L. Yelvington wrote:
> admittedly, i am not very familiar with sudo because i have never seen the
> practical advantages of making su'ing more of a hassle by having to manage
> another set of conf files and keeping track of who's a sudoer and,
> the
"Robert L. Yelvington" <[EMAIL PROTECTED]> writes:
> what's to stop a person, once they've sudo'd, from editing /etc/sudoers and
> giving themselves more privs?
sudo is to stop them, perhaps?
~Tim
--
15:40:15 up 9 days, 23:50, 12 users, load average: 0.19, 0.04, 0.01
[EMAIL PROTECTED] |The
admittedly, i am not very familiar with sudo because i have never seen the
practical advantages of making su'ing more of a hassle by having to manage
another set of conf files and keeping track of who's a sudoer and,
therefore, have chosen not to use it.
what's to stop a person, once they've sudo
On Fri, Jul 06, 2001 at 09:18:18AM -0400, Jason Healy wrote:
> types of
> passwords accepted to run root commands, etc).
elaborate.
the main reason i don't use sudo except for small things which cannot
grant a root shell in any way is for the simple reason the sudo
converts a normal unprivleged
1 - 100 of 124 matches
Mail list logo