On 4/9/21 10:47 AM, Binet, Valere (NIH/NIA/IRP) [C] wrote:
The NIST and CIS baselines don't allow su, we have to use sudo on government computers.
Could you enlighten me on the rationale behind that restriction? As, as you already noticed, my [ancient, maybe] reasoning makes me arrive at an opposite conclusion. (but mine is pure security consideration with full trust vested into sysadmin, see below...)
On a second guess: it is just for a separation of privileges, and accounting of who did what which sudo brings to the table... Right?
Thanks in advance.
Valeri
Valère Binet
On 4/9/21, 11:39 AM, "Valeri Galtsev" galtsev@kicp.uchicago.edu wrote:
On 4/9/21 10:31 AM, Johnny Hughes wrote: > On 4/9/21 5:18 AM, Steve Clark via CentOS wrote: >> On 4/8/21 3:50 PM, Tony Schreiner wrote: >> >> On Thu, Apr 8, 2021 at 2:33 PM Nicolas Kovacs >> <info@microlinux.fr><mailto:info@microlinux.fr> wrote: >> >> >> >> Le 08/04/2021 à 18:58, Steve Clark via CentOS a écrit : >> >> >> How do I allow root log in on GDM. >> >> >> >> tl;dr: you don't. >> >> Log in as a non-root user, and when you do need root, either open up a >> terminal >> and use 'su -' or (even better) setup your user by making your user a >> member of >> the wheel group and then use sudo. >> >> Logging in to a GUI as root is *BAD* practice. >> >> Cheers, >> >> Niki >> >> >> >> >> >> That said - you can do it, by clicking on "Not listed?" and typing root >> into the user field. >> >> Yes I have done that and it immediately comes back to the login screen, >> I know I am typing the >> correct passwd, because if I botch the passwd I get a message to that >> effect. >> >> >> > > I would not recommend ever using the GUI as the root user .. it creates > keys and items that are very dangerous. (gnome key rings, etc) > +1000 > You should be able to 'su -' , then use visudo to create a sudo account > for your user. You can even NOPASSWD your user for using sudo (you may > or may not want to do that .. if someone gains access to your local > account, they could then sudo with no passwd). > In the past I even avoided sudo. It yet one more SUID-ed binary on your machine. Which may add to your potential [local, in general] vulnerability footprint. su, - making yourself root is more than enough for regular sysadmin. > But, i have never, ever logged in as root on a GUI account directly on a > machine that I cared about or was keeping live .. just advise, do with > it what you will. > +1 To OP: Do as you wish, and deal with consequences. Valeri > > _______________________________________________ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > -- ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++ _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Fri, 9 Apr 2021 at 12:02, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On 4/9/21 10:47 AM, Binet, Valere (NIH/NIA/IRP) [C] wrote:
The NIST and CIS baselines don't allow su, we have to use sudo on
government computers.
Could you enlighten me on the rationale behind that restriction? As, as you already noticed, my [ancient, maybe] reasoning makes me arrive at an opposite conclusion. (but mine is pure security consideration with full trust vested into sysadmin, see below...)
On a second guess: it is just for a separation of privileges, and accounting of who did what which sudo brings to the table... Right?
sudo brings into accounting and the ability to restrict a person to a single command. [That is hard to do well but it is possible.] It also allows for an easily auditable configuration file set so that you can see what should have been allowed and what shouldn't. Versus the usual 'oh lets make it setgid blah or setuid foo but restricted to this group..' and people forgetting it was done that way or why.
That said it is like any tool can be used as a hammer when it should have remained a phillips head.
On Fri, 9 Apr 2021 at 12:19, Stephen John Smoogen smooge@gmail.com wrote:
On Fri, 9 Apr 2021 at 12:02, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On 4/9/21 10:47 AM, Binet, Valere (NIH/NIA/IRP) [C] wrote:
The NIST and CIS baselines don't allow su, we have to use sudo on
government computers.
Could you enlighten me on the rationale behind that restriction? As, as you already noticed, my [ancient, maybe] reasoning makes me arrive at an opposite conclusion. (but mine is pure security consideration with full trust vested into sysadmin, see below...)
On a second guess: it is just for a separation of privileges, and accounting of who did what which sudo brings to the table... Right?
sudo brings into accounting and the ability to restrict a person to a single command. [That is hard to do well but it is possible.] It also allows for an easily auditable configuration file set so that you can see what should have been allowed and what shouldn't. Versus the usual 'oh lets make it setgid blah or setuid foo but restricted to this group..' and people forgetting it was done that way or why.
That said it is like any tool can be used as a hammer when it should have remained a phillips head.
Finally sudo can allow for better RBAC rules where if that is needed you had to have multiple su commands that were aligned to each role so that people could not escape their jail. [My understanding is that this is where your chosen OS shines with sudo and this was lifted to other os's laster.] By 2005 most .gov/.mil baselines required su to be no longer allowed because of this.
On 4/9/21 11:23 AM, Stephen John Smoogen wrote:
On Fri, 9 Apr 2021 at 12:19, Stephen John Smoogen smooge@gmail.com wrote:
On Fri, 9 Apr 2021 at 12:02, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On 4/9/21 10:47 AM, Binet, Valere (NIH/NIA/IRP) [C] wrote:
The NIST and CIS baselines don't allow su, we have to use sudo on
government computers.
Could you enlighten me on the rationale behind that restriction? As, as you already noticed, my [ancient, maybe] reasoning makes me arrive at an opposite conclusion. (but mine is pure security consideration with full trust vested into sysadmin, see below...)
On a second guess: it is just for a separation of privileges, and accounting of who did what which sudo brings to the table... Right?
sudo brings into accounting and the ability to restrict a person to a single command. [That is hard to do well but it is possible.] It also allows for an easily auditable configuration file set so that you can see what should have been allowed and what shouldn't. Versus the usual 'oh lets make it setgid blah or setuid foo but restricted to this group..' and people forgetting it was done that way or why.
That said it is like any tool can be used as a hammer when it should have remained a phillips head.
Finally sudo can allow for better RBAC rules where if that is needed you had to have multiple su commands that were aligned to each role so that people could not escape their jail. [My understanding is that this is where your chosen OS shines
Which one OS would be that?
Valeri
with sudo and this was lifted to other os's laster.] By 2005 most .gov/.mil baselines required su to be no longer allowed because of this.
On Fri, Apr 09, 2021 at 11:39:58AM -0500, Valeri Galtsev wrote:
On 4/9/21 11:23 AM, Stephen John Smoogen wrote:
On Fri, 9 Apr 2021 at 12:19, Stephen John Smoogen smooge@gmail.com wrote:
On Fri, 9 Apr 2021 at 12:02, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Finally sudo can allow for better RBAC rules where if that is needed you had to have multiple su commands that were aligned to each role so that people could not escape their jail. [My understanding is that this is where your chosen OS shines
Which one OS would be that?
I suspect that it's because you are known as the FreeBSD user on this list. :) (I also prefer it, and have been fortunate enough to be at a FreeBSD shop for yearse now.) Note that FreeBSD can also use OpenBSD's doas command, though on FreeBSD, there is no persist option, so one must type the password each time--which in a production environment isn't necessary a bad thing.
On 4/9/21 1:08 PM, Scott Robbins wrote:
On Fri, Apr 09, 2021 at 11:39:58AM -0500, Valeri Galtsev wrote:
On 4/9/21 11:23 AM, Stephen John Smoogen wrote:
On Fri, 9 Apr 2021 at 12:19, Stephen John Smoogen smooge@gmail.com wrote:
On Fri, 9 Apr 2021 at 12:02, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Finally sudo can allow for better RBAC rules where if that is needed you had to have multiple su commands that were aligned to each role so that people could not escape their jail. [My understanding is that this is where your chosen OS shines
Which one OS would be that?
I suspect that it's because you are known as the FreeBSD user on this list. :)
Oh boy, I never could imagine I could be "known as...". Who would ever even notice me?! ;-)
(I also prefer it, and have been fortunate enough to be at a
FreeBSD shop for yearse now.) Note that FreeBSD can also use OpenBSD's doas command, though on FreeBSD, there is no persist option, so one must type the password each time--which in a production environment isn't necessary a bad thing.
You learn something every day. Thanks!
Valeri
On Fri, 9 Apr 2021 at 12:40, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On 4/9/21 11:23 AM, Stephen John Smoogen wrote:
On Fri, 9 Apr 2021 at 12:19, Stephen John Smoogen smooge@gmail.com
wrote:
On Fri, 9 Apr 2021 at 12:02, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On 4/9/21 10:47 AM, Binet, Valere (NIH/NIA/IRP) [C] wrote:
The NIST and CIS baselines don't allow su, we have to use sudo on
government computers.
Could you enlighten me on the rationale behind that restriction? As, as you already noticed, my [ancient, maybe] reasoning makes me arrive at
an
opposite conclusion. (but mine is pure security consideration with full trust vested into sysadmin, see below...)
On a second guess: it is just for a separation of privileges, and accounting of who did what which sudo brings to the table... Right?
sudo brings into accounting and the ability to restrict a person to a single command. [That is hard to do well but it is possible.] It also allows for an easily auditable configuration file set so that you can
see
what should have been allowed and what shouldn't. Versus the usual 'oh
lets
make it setgid blah or setuid foo but restricted to this group..' and people forgetting it was done that way or why.
That said it is like any tool can be used as a hammer when it should
have
remained a phillips head.
Finally sudo can allow for better RBAC rules where if that is needed you had to have multiple su commands that were aligned to each role so that people could not escape their jail. [My understanding is that this is
where
your chosen OS shines
that should have been written as
your chosen OS, FreeBSD, shines ...
my apology for dropping the packets as I thought i typed it but didn't
Which one OS would be that?
Valeri
with sudo and this was lifted to other os's laster.] By 2005 most .gov/.mil baselines required su to be no longer allowed because of this.
-- ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++ _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 4/9/21 1:15 PM, Stephen John Smoogen wrote:
On Fri, 9 Apr 2021 at 12:40, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On 4/9/21 11:23 AM, Stephen John Smoogen wrote:
On Fri, 9 Apr 2021 at 12:19, Stephen John Smoogen smooge@gmail.com
wrote:
On Fri, 9 Apr 2021 at 12:02, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On 4/9/21 10:47 AM, Binet, Valere (NIH/NIA/IRP) [C] wrote:
The NIST and CIS baselines don't allow su, we have to use sudo on
government computers.
Could you enlighten me on the rationale behind that restriction? As, as you already noticed, my [ancient, maybe] reasoning makes me arrive at
an
opposite conclusion. (but mine is pure security consideration with full trust vested into sysadmin, see below...)
On a second guess: it is just for a separation of privileges, and accounting of who did what which sudo brings to the table... Right?
sudo brings into accounting and the ability to restrict a person to a single command. [That is hard to do well but it is possible.] It also allows for an easily auditable configuration file set so that you can
see
what should have been allowed and what shouldn't. Versus the usual 'oh
lets
make it setgid blah or setuid foo but restricted to this group..' and people forgetting it was done that way or why.
That said it is like any tool can be used as a hammer when it should
have
remained a phillips head.
Finally sudo can allow for better RBAC rules where if that is needed you had to have multiple su commands that were aligned to each role so that people could not escape their jail. [My understanding is that this is
where
your chosen OS shines
that should have been written as
your chosen OS, FreeBSD, shines ...
Ah, I couldn't imagine someone remembers I use FreeBSD too. On servers that is. Number crunchers, workstations, and laptops of my users run CentOS (7), Ubuntu (laptops), and also Debian these days. Not mentioning MS Windows and MacOS, though probably should. As these are my choices too as well as those of my users.
my apology for dropping the packets as I thought i typed it but didn't
No need to apologize. I was indeed a bit puzzled thinking this must be something obvious - derived from the fact this is CentOS list maybe - still it was kind of escaping me so I asked ;-)
Yes, I did start rating sudo higher than I did in the past after this thread (hijacked - my apologies if it was my doing, didn't mean though).
Thanks, everybody, for your insights !
Valeri
Which one OS would be that?
Valeri
with sudo and this was lifted to other os's laster.] By 2005 most .gov/.mil baselines required su to be no longer allowed because of this.
-- ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++ _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-
Scott Robbins -
Stephen John Smoogen -
Valeri Galtsev