Re: Don't try this at home kids

2021-12-05 Thread Andrei POPESCU
On Lu, 29 nov 21, 22:42:01, David Wright wrote:
> 
> You don't have to use sudo in the manner shown above. You can use
> it to allow certain users to run certain commands. I use it to run
> a defined set of routine commands without having to bother to switch
> to root, or to authenticate, or be careful, or be sober.

Considering sudoers syntax is less than intuitive an example might be in 
order:


# members of adm can run certain commands as root without supplying 
# a password
Cmnd_AliasADM_COMMANDS = /usr/bin/dmesg, \
 /usr/bin/apt update, \
 /usr/bin/apt upgrade, \
 /usr/bin/apt autoremove --purge, \
 /usr/sbin/reboot, \
 /usr/sbin/poweroff

%adm  ALL = (root) NOPASSWD: ADM_COMMANDS 


(since /etc/sudoers is a conffile I prefer to have the above in a file 
under /etc/sudoers.d/)


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Re: Don't try this at home kids

2021-12-05 Thread Andrei POPESCU
On Ma, 30 nov 21, 12:19:05, Joe Pfeiffer wrote:
> Paul Johnson  writes:
> >
> > Make sure you log out and log back in after you do 'adduser joe 
> > sudo' (or whatever your username is). Group permissions are 
> > generally only effective as they were at the time of that session's 
> > login.
> 
> While you're right about need to log out and back in again after changes
> to /etc/sudoers, 

You might want to reread what Paul wrote ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Re: Don't try this at home kids

2021-12-02 Thread Nicholas Geovanis
On Mon, Nov 29, 2021, 10:27 PM Tom Dial  wrote:

>
>
> On 11/29/21 17:19, Nicholas Geovanis wrote:
> > On Mon, Nov 29, 2021, 5:14 PM James H. H. Lampert <
> jam...@touchtonecorp.com > wrote:
> >
> >  And the only
> > reason ROOT access is more dangerous than, say, QSECOFR access on
> OS/400
> > (or whatever IBM is calling it this week) is because there's nothing
> > stopping a Linux ROOT from doing things *nobody* should be allowed
> to do
> > without putting the system into some kind of maintenance mode.
> >
> >
> > Well selinux stops root from doing those things. But im the only known
> human who doesn't dislike selinux. And other problems I have
> > :-D
>
> You are not the only one who doesn't dislike or maybe even likes selinux.
> I consider it technically superior to apparmor as a mandatory access
> control system, and maybe both more flexible and user-friendlier as well. I
> found it generally fairly easy to find good documentation (e. g., Red Hat).
>

Redhat's doc is probably the best. But they ship it in several
pre-configured but non-complete base configurations. Like their "targeted
mode".

And I expect those who originated it, some still employed at USNSA, also
> think well of it, along with the current maintainers and likely enough
> quite a few other users.
>

The "rainbow books" are freely available on Google books nowadays. They
were NCSC (NSA) guidelines for highly secure govt systems. I implemented B1
level security (Orange book, Green book) (MAC like selinux) in 1990 in Unix
OS's. Went thru the evaluation process with them.

Regards,
> Tom Dial
>
> >
> >
> > ...
> > --
> > JHHL
> >
>
>


Re: Don't try this at home kids

2021-12-02 Thread David Wright
On Tue 30 Nov 2021 at 13:15:56 (-0500), Greg Wooledge wrote:
> On Tue, Nov 30, 2021 at 11:12:49AM -0600, Paul Johnson wrote:
> > On Mon, Nov 29, 2021 at 11:57 PM Joe Pfeiffer  wrote:
> > > David Wright  writes:
> > > > As /etc/sudoers already contains the line:
> > > >
> > > >   %sudo   ALL=(ALL:ALL) ALL
> > > >
> > > > one should be able to achieve the same effect by
> > > > adding the user to the sudo group.
> > >
> > > Near as I can tell from my experience, that doesn't work around the
> > > password requirement.

Yes, I don't really approve of the original request. It's one thing
to allow using a closed set of specific, routine commands without
a password, as I do, but to open up the whole system by typing sudo
at the start of a line seems like going a bit too far for me.

It's bad enough that after typing it once, AIUI, you get 15 mins of
passwordless freedom. However, can you not use that to your advantage
by increasing the default timeout to a value that suits you?

Presumably, typing the password once in, say, 9 hours, is not too
onerous, and a major advantage is that it's revokable, merely by
closing the terminal that you typed it into. OTOH, NOPASSWD: leaves
all your sessionS wide open, as it's not revokable.

> > Make sure you log out and log back in after you do 'adduser joe sudo' (or
> > whatever your username is). Group permissions are generally only effective
> > as they were at the time of that session's login.
> 
> What you said is correct, but it doesn't contradict the paragraph that
> you cited.
> 
> Adding yourself to the sudo group (and then re-logging-in) allows you
> to use sudo.  It doesn't skip the password requirement.
> 
> To skip the password requirement, you need to make edits, either to the
> main sudoers file or to a drop-in file.  Instructions have already been
> given earlier in this thread.  It involves adding the string NOPASSWD
> and some punctuation in the right position in a ridiculously overengineered
> file.

It's difficult to imagine using the flexibility that   man sudoers
demonstrates. But then, I've never had to administer a system that's
subject to the excessive ingenuity that some people (think students)
can show.

Cheers,
David.



Re: Don't try this at home kids

2021-11-30 Thread Joe Pfeiffer
Paul Johnson  writes:

> On Mon, Nov 29, 2021 at 11:57 PM Joe Pfeiffer  wrote:
>
>  David Wright  writes:
>
>  > On Mon 29 Nov 2021 at 17:47:24 (-0500), Jude DaShiell wrote:
>  >> sudo doesn't ask me for my password and I didn't even touch /etc/sudoers
>  >> to do it.  A file placed in /etc/sudoers.d with permissions of 0440 having
>  >> any name you choose and contents like:
>  >> user ALL=(ALL) NOPASSWD:ALL
>  >> in it with user being the account name will do it.
>  >
>  > As /etc/sudoers already contains the line:
>  >
>  >   %sudo   ALL=(ALL:ALL) ALL
>  >
>  > one should be able to achieve the same effect by
>  > adding the user to the sudo group.
>
>  Near as I can tell from my experience, that doesn't work around the
>  password requirement.
>
> Make sure you log out and log back in after you do 'adduser joe sudo' (or 
> whatever your username is). Group permissions are generally only effective as
> they were at the time of that session's login.

While you're right about need to log out and back in again after changes
to /etc/sudoers, my /etc/sudoers files have had the %sudo   ALL=(ALL:ALL) ALL
line for *years*.

Do you by any chance have your system set up so you can login without a
password?  That's a guess at something that might explain the
difference.



Re: Don't try this at home kids

2021-11-30 Thread Greg Wooledge
On Tue, Nov 30, 2021 at 11:12:49AM -0600, Paul Johnson wrote:
> On Mon, Nov 29, 2021 at 11:57 PM Joe Pfeiffer  wrote:
> > David Wright  writes:
> > > As /etc/sudoers already contains the line:
> > >
> > >   %sudo   ALL=(ALL:ALL) ALL
> > >
> > > one should be able to achieve the same effect by
> > > adding the user to the sudo group.
> >
> > Near as I can tell from my experience, that doesn't work around the
> > password requirement.
> 
> Make sure you log out and log back in after you do 'adduser joe sudo' (or
> whatever your username is). Group permissions are generally only effective
> as they were at the time of that session's login.

What you said is correct, but it doesn't contradict the paragraph that
you cited.

Adding yourself to the sudo group (and then re-logging-in) allows you
to use sudo.  It doesn't skip the password requirement.

To skip the password requirement, you need to make edits, either to the
main sudoers file or to a drop-in file.  Instructions have already been
given earlier in this thread.  It involves adding the string NOPASSWD
and some punctuation in the right position in a ridiculously overengineered
file.



Re: Don't try this at home kids

2021-11-30 Thread Paul Johnson
On Mon, Nov 29, 2021 at 11:57 PM Joe Pfeiffer  wrote:

> David Wright  writes:
>
> > On Mon 29 Nov 2021 at 17:47:24 (-0500), Jude DaShiell wrote:
> >> sudo doesn't ask me for my password and I didn't even touch /etc/sudoers
> >> to do it.  A file placed in /etc/sudoers.d with permissions of 0440
> having
> >> any name you choose and contents like:
> >> user ALL=(ALL) NOPASSWD:ALL
> >> in it with user being the account name will do it.
> >
> > As /etc/sudoers already contains the line:
> >
> >   %sudo   ALL=(ALL:ALL) ALL
> >
> > one should be able to achieve the same effect by
> > adding the user to the sudo group.
>
> Near as I can tell from my experience, that doesn't work around the
> password requirement.
>

Make sure you log out and log back in after you do 'adduser joe sudo' (or
whatever your username is). Group permissions are generally only effective
as they were at the time of that session's login.


Re: Don't try this at home kids

2021-11-29 Thread Joe Pfeiffer
David Wright  writes:

> On Mon 29 Nov 2021 at 17:47:24 (-0500), Jude DaShiell wrote:
>> sudo doesn't ask me for my password and I didn't even touch /etc/sudoers
>> to do it.  A file placed in /etc/sudoers.d with permissions of 0440 having
>> any name you choose and contents like:
>> user ALL=(ALL) NOPASSWD:ALL
>> in it with user being the account name will do it.
>
> As /etc/sudoers already contains the line:
>
>   %sudo   ALL=(ALL:ALL) ALL
>
> one should be able to achieve the same effect by
> adding the user to the sudo group.

Near as I can tell from my experience, that doesn't work around the
password requirement.



Re: Don't try this at home kids

2021-11-29 Thread David Wright
On Mon 29 Nov 2021 at 17:47:24 (-0500), Jude DaShiell wrote:
> sudo doesn't ask me for my password and I didn't even touch /etc/sudoers
> to do it.  A file placed in /etc/sudoers.d with permissions of 0440 having
> any name you choose and contents like:
> user ALL=(ALL) NOPASSWD:ALL
> in it with user being the account name will do it.

As /etc/sudoers already contains the line:

  %sudo   ALL=(ALL:ALL) ALL

one should be able to achieve the same effect by
adding the user to the sudo group.

> On Tue, 30 Nov 2021, Jeremy Ardley wrote:

> > edit /etc/sudoers and modify / add
> >
> > username ALL=(ALL) NOPASSWD:ALL
> >
> > P.S. I am totally unconvinced about the arguments for using sudo rather than
> > running as root. You can do exactly the same damage with sudo as being root
> > user.

You don't have to use sudo in the manner shown above. You can use
it to allow certain users to run certain commands. I use it to run
a defined set of routine commands without having to bother to switch
to root, or to authenticate, or be careful, or be sober.

> > P.P.S The conventional instruction is to use visudo to do the edits. Which
> > means using Vi, which is another anachronism that should be humanely put 
> > down.

Not here. The only editor I run as root is nano, whether I start it
with visudo, vi, vim, emacs, etc. They're all aliased to nano (except
the first), and always have been. (Or ae, back in the mists of time.)

Cheers,
David.



Re: Don't try this at home kids

2021-11-29 Thread Tom Dial



On 11/29/21 17:19, Nicholas Geovanis wrote:
> On Mon, Nov 29, 2021, 5:14 PM James H. H. Lampert  > wrote:
> 
>  And the only
> reason ROOT access is more dangerous than, say, QSECOFR access on OS/400
> (or whatever IBM is calling it this week) is because there's nothing
> stopping a Linux ROOT from doing things *nobody* should be allowed to do
> without putting the system into some kind of maintenance mode.
> 
> 
> Well selinux stops root from doing those things. But im the only known human 
> who doesn't dislike selinux. And other problems I have
> :-D

You are not the only one who doesn't dislike or maybe even likes selinux. I 
consider it technically superior to apparmor as a mandatory access control 
system, and maybe both more flexible and user-friendlier as well. I found it 
generally fairly easy to find good documentation (e. g., Red Hat).

And I expect those who originated it, some still employed at USNSA, also think 
well of it, along with the current maintainers and likely enough quite a few 
other users.

Regards,
Tom Dial

> 
> 
> ...
> --
> JHHL
> 



Re: Don't try this at home kids

2021-11-29 Thread Nicholas Geovanis
On Mon, Nov 29, 2021, 5:14 PM James H. H. Lampert 
wrote:

>  And the only
> reason ROOT access is more dangerous than, say, QSECOFR access on OS/400
> (or whatever IBM is calling it this week) is because there's nothing
> stopping a Linux ROOT from doing things *nobody* should be allowed to do
> without putting the system into some kind of maintenance mode.
>

Well selinux stops root from doing those things. But im the only known
human who doesn't dislike selinux. And other problems I have
:-D

>
...
> --
> JHHL
>
>


Re: Don't try this at home kids

2021-11-29 Thread John Hasler
Jeremy Ardley wrote:
> P.P.S The conventional instruction is to use visudo to do the
> edits. Which means using Vi, which is another anachronism that should
> be humanely put down.

Visudo will use whatever editor you configure it to use.  Read the
visudo man page.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA



Re: Don't try this at home kids

2021-11-29 Thread Bob Bernstein

On Mon, 29 Nov 2021, James H. H. Lampert wrote:

And the only reason ROOT access is more dangerous than, say, 
QSECOFR access on OS/400 (or whatever IBM is calling it this 
week) is because there's nothing stopping a Linux ROOT from 
doing things *nobody* should be allowed to do without putting 
the system into some kind of maintenance mode.


Yes. But, James, if you keep that kind of talk going in these 
public venues, some bright young addled thing in HR with 
hotpants for her boss' job, will pull your personnel jacket and 
see if she can't nudge you along to early (or late!) retirement.


Don't take any guff off those swine.

Keep it up!

--
"The existence of God is not an experimental issue in the way it was."

   John Wisdom - "Gods" (1944)



Re: Don't try this at home kids

2021-11-29 Thread Jeremy Ardley


On 30/11/21 7:14 am, James H. H. Lampert wrote:


I have access to a number of Amazon Linux virtual boxes, that don't 
like password authentication in general (preferring certificate 
authentication . . . which authenticates the BOX that is ssh-ing in, 
but not the WARM BODY between the chair and the keyboard).



On the topic of SSH certificates, they seem fine at first, but when you 
delve deeper they are a serious security risk because they are are 
issued by individual users and are effectively unmanaged and 
unmaintained. In large organisations they are a nightmare to control.


The current best practice is to use a third party authenticator where 
access control is centrally managed. Even so, automatic authentication 
means you have no control over the warm body or hacking script that is 
using it.



--
Jeremy



OpenPGP_signature
Description: OpenPGP digital signature


Re: Don't try this at home kids

2021-11-29 Thread James H. H. Lampert

On 11/29/21 2:41 PM, Jeremy Ardley wrote:
P.S. I am totally unconvinced about the arguments for using sudo rather 
than running as root. You can do exactly the same damage with sudo as 
being root user.
P.P.S The conventional instruction is to use visudo to do the edits. 
Which means using Vi, which is another anachronism that should be 
humanely put down.


That's about the size of it. I've used forty-year-old non-full-screen 
editors that are a hundred times more intuitive than vi is. And the only 
reason ROOT access is more dangerous than, say, QSECOFR access on OS/400 
(or whatever IBM is calling it this week) is because there's nothing 
stopping a Linux ROOT from doing things *nobody* should be allowed to do 
without putting the system into some kind of maintenance mode.


I have access to a number of Amazon Linux virtual boxes, that don't like 
password authentication in general (preferring certificate 
authentication . . . which authenticates the BOX that is ssh-ing in, but 
not the WARM BODY between the chair and the keyboard).


And if you have a system that doesn't allow ROOT to sign on, and doesn't 
allow you to SU, then you can achieve the same result by doing


  sudo bash

--
JHHL



Re: Don't try this at home kids

2021-11-29 Thread Igor Korot
Hi,

On Mon, Nov 29, 2021 at 4:50 PM Pierre-Elliott Bécue  wrote:
>
>
> Hello,
>
> Bob Bernstein  wrote on 29/11/2021 at 23:25:52+0100:
>
> > How do I tell sudo not to ask me for my password?
> >
> > It's me. I'm on my computer. I already logged in with my password. No
> > one else is logged on.
> >
> > I know all you purists out there are rending your garments if not your
> > flesh. but c'mon sudo! Can't a brother catch a break around here?
> >
> > Thank you.
>
> While I would still recommend you not to do that, here is how you can do
> it.
>
> man 5 sudoers reads:
>
> > PASSWD and NOPASSWD
> >
> >   By default, sudo requires that a user authenticate him or herself
> >   before running a command.  This behavior can be modified via the
> >   NOPASSWD tag.  Like a Runas_Spec, the NOPASSWD tag sets a default
> >   for the commands that follow it in the Cmnd_Spec_List.
> >   Conversely, the PASSWD tag can be used to reverse things.  For
> >   exam‐ ple:
> >
> >   ray rushmore = NOPASSWD: /bin/kill, /bin/ls, /usr/bin/lprm
> >
> >   would allow the user ray to run /bin/kill, /bin/ls, and
> >   /usr/bin/lprm as root on the machine rushmore with‐ out
> >   authenticating himself.  If we only want ray to be able to run
> >   /bin/kill without a password the entry would be:
> >
> >   ray rushmore = NOPASSWD: /bin/kill, PASSWD: /bin/ls, /usr/bin/lprm
> >
> >   Note, however, that the PASSWD tag has no effect on users who are
> >   in the group specified by the exempt_group setting.
> >
> >   By default, if the NOPASSWD tag is applied to any of a user's
> >   entries for the current host, the user will be able to run “sudo
> >   -l” without a password.  Additionally, a user may only run “sudo
> >   -v” without a pass‐ word if all of the user's entries for the
> >   current host have the NOPASSWD tag.  This behavior may be over‐
> >   ridden via the verifypw and listpw options.
>
> Have a read at visudo's manpage, too. I won't give you the exact line to
> type, as it's a nice way to make sure you understand what you are doing.
>
> But still, you should consider not doing so, as it can bite back
> strongly should your computer be accessed by someone else while you're
> not at your desk and still logged in.

Especially if you have any kind of children... ;-)

Thank you.

>
> Anyway, meh.
>
> --
> PEB



Re: Don't try this at home kids

2021-11-29 Thread Pierre-Elliott Bécue

Hello,

Bob Bernstein  wrote on 29/11/2021 at 23:25:52+0100:

> How do I tell sudo not to ask me for my password?
>
> It's me. I'm on my computer. I already logged in with my password. No
> one else is logged on.
>
> I know all you purists out there are rending your garments if not your
> flesh. but c'mon sudo! Can't a brother catch a break around here?
>
> Thank you.

While I would still recommend you not to do that, here is how you can do
it.

man 5 sudoers reads:

> PASSWD and NOPASSWD
>
>   By default, sudo requires that a user authenticate him or herself
>   before running a command.  This behavior can be modified via the
>   NOPASSWD tag.  Like a Runas_Spec, the NOPASSWD tag sets a default
>   for the commands that follow it in the Cmnd_Spec_List.
>   Conversely, the PASSWD tag can be used to reverse things.  For
>   exam‐ ple:
>
>   ray rushmore = NOPASSWD: /bin/kill, /bin/ls, /usr/bin/lprm
>
>   would allow the user ray to run /bin/kill, /bin/ls, and
>   /usr/bin/lprm as root on the machine rushmore with‐ out
>   authenticating himself.  If we only want ray to be able to run
>   /bin/kill without a password the entry would be:
>
>   ray rushmore = NOPASSWD: /bin/kill, PASSWD: /bin/ls, /usr/bin/lprm
>
>   Note, however, that the PASSWD tag has no effect on users who are
>   in the group specified by the exempt_group setting.
>
>   By default, if the NOPASSWD tag is applied to any of a user's
>   entries for the current host, the user will be able to run “sudo
>   -l” without a password.  Additionally, a user may only run “sudo
>   -v” without a pass‐ word if all of the user's entries for the
>   current host have the NOPASSWD tag.  This behavior may be over‐
>   ridden via the verifypw and listpw options.

Have a read at visudo's manpage, too. I won't give you the exact line to
type, as it's a nice way to make sure you understand what you are doing.

But still, you should consider not doing so, as it can bite back
strongly should your computer be accessed by someone else while you're
not at your desk and still logged in.

Anyway, meh.

-- 
PEB


signature.asc
Description: PGP signature


Re: Don't try this at home kids

2021-11-29 Thread Darac Marjal

On 29/11/2021 22:41, Jeremy Ardley wrote:
>
> On 30/11/21 6:25 am, Bob Bernstein wrote:
>> How do I tell sudo not to ask me for my password?
>>
>> It's me. I'm on my computer. I already logged in with my password. No
>> one else is logged on.
>>
>> I know all you purists out there are rending your garments if not
>> your flesh. but c'mon sudo! Can't a brother catch a break around here?
>>
>> Thank you.
>>
> edit /etc/sudoers and modify / add
>
> username ALL=(ALL) NOPASSWD:ALL
>
> P.S. I am totally unconvinced about the arguments for using sudo
> rather than running as root. You can do exactly the same damage with
> sudo as being root user.
"sudo" is supposed to be used as part of a wider ecosystem. By
encouraging users to run "sudo foo" rather than running "foo" directly
as root, sudo can trigger audit events and so on.
> P.P.S The conventional instruction is to use visudo to do the edits.
> Which means using Vi, which is another anachronism that should be
> humanely put down.
Actually, sudo will run $SUDO_EDITOR or else $VISUAL (hence the name) or
else $EDITOR.  So, you can use emacs or joe or nano or anything like
that, if you prefer.



OpenPGP_signature
Description: OpenPGP digital signature


Re: Don't try this at home kids

2021-11-29 Thread Jude DaShiell
sudo doesn't ask me for my password and I didn't even touch /etc/sudoers
to do it.  A file placed in /etc/sudoers.d with permissions of 0440 having
any name you choose and contents like:
user ALL=(ALL) NOPASSWD:ALL
in it with user being the account name will do it.


On Tue, 30 Nov 2021, Jeremy Ardley wrote:

>
> On 30/11/21 6:25 am, Bob Bernstein wrote:
> > How do I tell sudo not to ask me for my password?
> >
> > It's me. I'm on my computer. I already logged in with my password. No one
> > else is logged on.
> >
> > I know all you purists out there are rending your garments if not your
> > flesh. but c'mon sudo! Can't a brother catch a break around here?
> >
> > Thank you.
> >
> edit /etc/sudoers and modify / add
>
> username ALL=(ALL) NOPASSWD:ALL
>
> P.S. I am totally unconvinced about the arguments for using sudo rather than
> running as root. You can do exactly the same damage with sudo as being root
> user.
> P.P.S The conventional instruction is to use visudo to do the edits. Which
> means using Vi, which is another anachronism that should be humanely put down.
>
>



Re: Don't try this at home kids

2021-11-29 Thread Jeremy Ardley


On 30/11/21 6:25 am, Bob Bernstein wrote:

How do I tell sudo not to ask me for my password?

It's me. I'm on my computer. I already logged in with my password. No 
one else is logged on.


I know all you purists out there are rending your garments if not your 
flesh. but c'mon sudo! Can't a brother catch a break around here?


Thank you.


edit /etc/sudoers and modify / add

username ALL=(ALL) NOPASSWD:ALL

P.S. I am totally unconvinced about the arguments for using sudo rather 
than running as root. You can do exactly the same damage with sudo as 
being root user.
P.P.S The conventional instruction is to use visudo to do the edits. 
Which means using Vi, which is another anachronism that should be 
humanely put down.


--
Jeremy A



OpenPGP_signature
Description: OpenPGP digital signature