LinuxQuestions.org
Page 2 of 2 1 2
Show 50 post(s) from this thread on one page

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   Changing Root and Sudo pass (https://www.linuxquestions.org/questions/linux-newbie-8/changing-root-and-sudo-pass-4175590536/)

BW-userx 10-01-2016 03:32 PM
Quote:
Originally Posted by linux4evr5581 (Post 5612525)
Interesting stuff indeed, but I think it would just make people more Linux/GNU aware, and would inspire trying out different distros as a result. But idk everyone seems so content with Mac and Windows regardless..
they're the real slackers ... lol plus the general majority write software for them OS's. they get more support because of the ease of revenue, my option but I think its a good one ..

linux4evr5581 10-01-2016 03:39 PM
Yup, that's just the way it is :/

lazydog 10-02-2016 01:11 AM
Here is another thing about sudo. If you do not want your users to ever become root you need to lock sudo so they cannot sudo into a shell. Reason being is once issuing the command (bash in this example) sudo bash they become root. Sudo is very powerful is used correctly and very dangerous if used incorrectly.

linux4evr5581 10-02-2016 05:45 AM
Quote:
Originally Posted by lazydog (Post 5612639)
Here is another thing about sudo. If you do not want your users to ever become root you need to lock sudo so they cannot sudo into a shell. Reason being is once issuing the command (bash in this example) sudo bash they become root. Sudo is very powerful is used correctly and very dangerous if used incorrectly.
Do you mean lock down sudo? Cus im trying to do that already, like i'm tring to figure out what commands require root priviledges. I know networking commands and commands in /sbin do.. I also want to block commands that dont need root but that still may be a risk for users to use...And im looking into what defualt file permissions are risks, and which ones I can change without hampering the system. I was going to study Damn Vulnerable Linux but I guess their not there anymore?

Turbocapitalist 10-02-2016 05:55 AM
Quote:
Originally Posted by linux4evr5581 (Post 5612686)
Do you mean lock down sudo? Cus im already trying to do that, like i'm tring to figure out what commands require root priviledges.
The only way to lock it down is to whitelist that which you want to allow for the accounts other than the admin account and to not use the admin account except when you need to whitelist specific tasks. Again, I'd recommend the "sudo" resources mentioned above, either the book or the presentation. MWL did a video of the presentation and it can be found under the same name "sudo: you're doing it wrong" on Youtube, and maybe some other places. The book is worth getting, even though it's not long.

linux4evr5581 10-02-2016 06:30 AM
I was aware sudoers had a whitelist in env_keep and env_check but I dont know how to edit that.. I'll look into those resources you mentioned thank you.

BW-userx 10-02-2016 01:07 PM
Quote:
Originally Posted by linux4evr5581 (Post 5612686)
Do you mean lock down sudo? Cus im trying to do that already, like i'm tring to figure out what commands require root priviledges. I know networking commands and commands in /sbin do.. I also want to block commands that dont need root but that still may be a risk for users to use...And im looking into what defualt file permissions are risks, and which ones I can change without hampering the system. I was going to study Damn Vulnerable Linux but I guess their not there anymore?
form my understanding anything on the system side you got a have root preiveges, if you're assigned to a group with said provages well then what does that tell ya?

so the question to that person would then be, how do you lock down a sudo file when the only one allowed to edit it is them that have been given either the root password ot sudo rights. even then within the sudoers file you can limit what a sudo user can do. so all ya got a do is take away, that right to edit the sudo file.

ok I just created a user jumped into that user and did
Code:
sudo bash
and this is what I got.
Code:
[shithead@voided ~]$ sudo bash
Password:
shithead is not in the sudoers file.  This incident will be reported.
so I am still not understanding what he is talking about if someone issues a command sudo bash becacuse I have not given this user any rights whatsoever other then the basic user rights it deafults to.

so what ya mean LOCK DOWN the sudoers file? sounds like a ruse to me.

linux4evr5581 10-02-2016 05:33 PM
Quote:
Originally Posted by BW-userx (Post 5612815)
form my understanding anything on the system side you got a have root preiveges, if you're assigned to a group with said provages well then what does that tell ya?

so the question to that person would then be, how do you lock down a sudo file when the only one allowed to edit it is them that have been given either the root password ot sudo rights. even then within the sudoers file you can limit what a sudo user can do. so all ya got a do is take away, that right to edit the sudo file.

ok I just created a user jumped into that user and did
Code:
sudo bash
and this is what I got.
Code:
[shithead@voided ~]$ sudo bash
Password:
shithead is not in the sudoers file.  This incident will be reported.
so I am still not understanding what he is talking about if someone issues a command sudo bash becacuse I have not given this user any rights whatsoever other then the basic user rights it deafults to.

so what ya mean LOCK DOWN the sudoers file? sounds like a ruse to me.
Well with preventing a user from going into a shell i'm pretty sure all you do is put an ! after their name in /etc/shadow file...But in the case of locking down sudo isnt that relevent when you're an administrator and you have users who need sudo. Wouldnt that be the exception? Unless the better option which I learned from MWL (havent watched the whole vid yet) is just not to use sudo, but instead use groups who have a specific role. Unless you wanted to write policies for every sudo user. Not sure what would be more secure...

Turbocapitalist 10-02-2016 10:22 PM
Quote:
Originally Posted by linux4evr5581 (Post 5612906)
Well with preventing a user from going into a shell i'm pretty sure all you do is put an ! after their name in /etc/shadow file...
There are still plenty of ways around that. Whitelisting is not where you make a list of programs which the account is not allowed to run. That is blacklisting and does not work. Whitelisting is where the allowed actions are listed one by one. An example follows below.

Quote:
Originally Posted by linux4evr5581 (Post 5612906)
But in the case of locking down sudo isnt that relevent when you're an administrator and you have users who need sudo. Wouldnt that be the exception? Unless the better option which I learned from MWL (havent watched the whole vid yet) is just not to use sudo, but instead use groups who have a specific role. Unless you wanted to write policies for every sudo user. Not sure what would be more secure...
Yes. Where possible, using group privileges instead of sudo is a better option. So if you want access to a file or a directory, groups are the way to go. However, with services 'sudo' is necessary.

Locking down "sudo" means whitelisting actions. If you want someone to get root shell, you simply add them to a group that can do so. The following line does that and more for the group sudo:

Code:
%sudo  ALL=(ALL:ALL) ALL
Though once they have root shell, the 'and more' part is redundant. If your /etc/sudoers file has that line, don't add accounts to the group sudo. Make a new group for each set of tasks, and add accounts to those groups as needed.

Code:
%sudo ALL=(root:root) /usr/sbin/visudo ""
%admin ALL=(root:root) /usr/bin/apt-get
%webmasters ALL=(root:root) /usr/sbin/service apache2 start, /usr/sbin/service apache2 stop, \
            /usr/sbin/service apache2 restart, /usr/sbin/service apache2 status
So there, the accounts in sudo can run amok. The accounts in admin can install or remove programs from the official repository. Those in webmasters can start or stop the web server which, when combined with group write access to various files, is enough to administer the web server. Those in both groups can do either. If you need only to write web pages, then "sudo" is not needed and groups are enough.

However, even with the admin and webmasters examples above, there are probably ways around "apt-get" itself and maybe Apache via the configuration files. The former could certainly be more compartmentalized. However, "sudo" is a helper for people you already trust. If you don't trust them, they should not be working for you. And as far as intruders go, they've already gotten in too far and you missed detecting them in time.

lazydog 10-03-2016 02:17 PM
Quote:
Originally Posted by BW-userx (Post 5612815)
so I am still not understanding what he is talking about if someone issues a command sudo bash becacuse I have not given this user any rights whatsoever other then the basic user rights it deafults to.

so what ya mean LOCK DOWN the sudoers file? sounds like a ruse to me.
I am talking about users who already have SUDO rights. Some admins lock down what a user may do when they are given the user these special rights on the system but most do not. I am simply pointing out that you should lock them (the sudo user) out of launching any type of shell so they cannot elevate what commands they can run. Once they can run a shell with root privileges you no longer have them locked down and that user has all the same rights as root to do anything root can do including locking out root and all other users.

BW-userx 10-03-2016 02:26 PM
Quote:
Originally Posted by lazydog (Post 5613331)
I am talking about users who already have SUDO rights. Some admins lock down what a user may do when they are given the user these special rights on the system but most do not. I am simply pointing out that you should lock them (the sudo user) out of launching any type of shell so they cannot elevate what commands they can run. Once they can run a shell with root privileges you no longer have them locked down and that user has all the same rights as root to do anything root can do including locking out root and all other users.
doesn't that void out the reason they have the sudoers file able to modify it so that they can only do certin things? like someone else in here has been showing how to do?

lazydog 10-03-2016 02:40 PM
No void here. Just making people aware that not locking out execution of shells will still allow a user to gain more privileges then what they want them to have.

linux4evr5581 10-03-2016 03:07 PM
Quote:
Originally Posted by Turbocapitalist (Post 5612971)
There are still plenty of ways around that. Whitelisting is not where you make a list of programs which the account is not allowed to run. That is blacklisting and does not work. Whitelisting is where the allowed actions are listed one by one. An example follows below.



Yes. Where possible, using group privileges instead of sudo is a better option. So if you want access to a file or a directory, groups are the way to go. However, with services 'sudo' is necessary.

Locking down "sudo" means whitelisting actions. If you want someone to get root shell, you simply add them to a group that can do so. The following line does that and more for the group sudo:

Code:
%sudo  ALL=(ALL:ALL) ALL
Though once they have root shell, the 'and more' part is redundant. If your /etc/sudoers file has that line, don't add accounts to the group sudo. Make a new group for each set of tasks, and add accounts to those groups as needed.

Code:
%sudo ALL=(root:root) /usr/sbin/visudo ""
%admin ALL=(root:root) /usr/bin/apt-get
%webmasters ALL=(root:root) /usr/sbin/service apache2 start, /usr/sbin/service apache2 stop, \
            /usr/sbin/service apache2 restart, /usr/sbin/service apache2 status
So there, the accounts in sudo can run amok. The accounts in admin can install or remove programs from the official repository. Those in webmasters can start or stop the web server which, when combined with group write access to various files, is enough to administer the web server. Those in both groups can do either. If you need only to write web pages, then "sudo" is not needed and groups are enough.

However, even with the admin and webmasters examples above, there are probably ways around "apt-get" itself and maybe Apache via the configuration files. The former could certainly be more compartmentalized. However, "sudo" is a helper for people you already trust. If you don't trust them, they should not be working for you. And as far as intruders go, they've already gotten in too far and you missed detecting them in time.
Ohhhhh ok I get it now, makes sense. I knew what whitelisting was but I thought you had to set/edit some parameter or something. I see you changed ALL to root cus sudo doesnt need to run as everying, and then just type the command(s) you want them to have, and put "" so they can't run commands with arguments.. Awesome now I know what im doing thank you!!


All times are GMT -5. The time now is 05:30 PM.
Page 2 of 2 1 2
Show 50 post(s) from this thread on one page