PAM SU SUDO again

Linux_Kidd · 05-04-2012, 05:13 AM

need some refreshings on this.
one way to restrict SU is to use WHEEL group and then use pam_wheel as required for auth in pam.d/su, and then refernce WHEEL in SUDOERS

however, i think i read somewhere, using WHEEL isnt the best way, and, having pam_wheel.so doesnt stop users from trying to use SU (well, need to be in wheel group, but so does root?). is this correct? i know sometimes it is required to run some stuff as another uid, like oracle, so even to su oracle the root uid would need to be in wheel group?

my method was to chmod 700 su and not use WHEEL group, but create a new group and use that in SUDOERS. this then prevents anyone from trying to su root, etc.

are there any issues with chmod 700 su ???

also, in SUDOERS is there a way to restrict how su is used, like this

%super-admins ALL = (ALL) ALL
%sys-admins ALL= /usr/bin/su [!root] + anything else

so basically, one group can do anything, the other can do anything but not su to root

is this possible??
thnx.

acid_kewpie · 05-04-2012, 05:23 AM

Never let sudoers run su. It undermines the point of sudo in the first place. Use "sudo -i" for an interactive shell managed properly through sudo. don't use the two together, it kills kittens or something.

Linux_Kidd · 05-04-2012, 05:35 AM

sudo -i to another user ?? so if uid >500 does sudo -i root they still get prompt for password??

acid_kewpie · 05-04-2012, 05:42 AM

if that's how you've configured it. That's the point in sudo -i over su, flexibility.

Linux_Kidd · 05-04-2012, 08:52 AM

ok, but how would i enforce the user to type "sudo -i" ?

acid_kewpie · 05-04-2012, 08:54 AM

by them having no better way around it. If they can't use su, then what other options do they have?

if you put your account in wheel (or another arbitrary group) and require wheel for su, then that's your own access to su sorted, and they can go whistle for it.

Linux_Kidd · 05-04-2012, 02:51 PM

so how do you restrict "sudo -i root" to "sudo -i !=root" ?

acid_kewpie · 05-04-2012, 03:09 PM

TBH, I've never known, and I've been worried you'd ask! Trying to finally work it out, I think you just need to be able to run "ALL" as that user on that host.

%group hostname=(dest user) ALL

and hostname can be ALL of course.

I *think* that is how to do what you asked.

Linux_Kidd · 05-05-2012, 08:52 AM

i was asking like this

Cmnd_Alias NOHELLS = /bin/sh,/bin/bash
Cmnd_Alias NOSU = /bin/su
root ALL=(ALL) ALL
%superadmins ALL=(ALL) ALL
%sysadmins ALL= ALL, !NOHELLS, !NOSU

uid "mojoe" is in %sysadmins

i think you are suggesting a method in which i could "rm su", and then use "sudo -i mojoe", this gets me a interactive shell (sourcing the user env) with sudoers rules applied to "mojoe"? but how to restrict a uid from using "sudo -i uid" to uid's i dont want them to become? is this what you mean?

but, my method of using ! commands has a major issue:

Code:

It is generally not effective to "subtract"
       commands from ALL using the ! operator.  A
       user can trivially circumvent this by copying
       the desired command to a different name and
       then executing that.  For example:



           bill        ALL = ALL, !SU, !SHELLS 



       Doesn't really prevent bill from running the
       commands listed in SU or SHELLS since he can
       simply copy those commands to a different
       name, or use a shell escape from an editor
       or other program.  Therefore, these kind of
       restrictions should be considered advisory
       at best (and rein- forced by policy).

is removing su a viable solution for say an apache server in chroot?

Code:

I'd suggest disabling 'su' altogether and using 'sudo' for everything. By disabling, I mean any of:

    Exploiting any system-specific means of restricting access to 'su' (such as the group 'wheel' trick for BSD, or the Linux equivalent). Note that there is no formal standard for this; POSIX does not mandate the presence of 'su', for example.
    Remove it (rm -f /bin/su).
    Remove its execute permission bits (chmod o-x /bin/su or chmod go-x /bin/su).
    Remove its setuid permission bit (chmod u-s /bin/su).

The residual problem with disabling 'su' by removing it or removing permission bits is that some system scripts may depend on su being present. There isn't a particularly clean solution for that - but they are generally few and far between because 'su' prompts for a password and prompting isn't liked in scripted environments. The other time 'su' is used is when 'root' runs the command to become another user; this is supported by removing the setuid bit (user root can run it, but no-one else can do so usefully). You might reinforce that by removing public and possibly group execute permission too (chmod u-s,go-rwx /bin/su).

If you are not using one of the system-specific means, be very careful; test before putting this into production.

acid_kewpie · 05-05-2012, 01:54 PM

you shouldn't need to remove su at all, you simply make it non operational for users.

I think what you describe about "sudo -i uid" IS what I explained, you can have an entry like...

%sysadmins ALL=(mojoe) ALL

I think. so that lets them sudo -i -u mojoe" but not anyone else.

Linux_Kidd · 05-05-2012, 02:07 PM

ok, i think i have something to test with.
now just need to figure out why my CentOS 6.2 wont recognize sudoers properly.
thnx

sundialsvcs · 05-09-2012, 07:53 AM

Use PAM controls, not "sudoers."

There should be one, and only one, user on the system besides root that can become root, and that user should be a maintenance-user by some name which is e.g. responsible for maintaining all "local" software and files. If an ordinary user can do anything with elevated-privileges by any means then your system, I think, "is 'compromised' already."

For instance ... OS/X (and Linux, for that matter) users might crow about how "secure" their systems are, but if they can type sudo su and enter their own password (if they have one...) to get there, then the "root password" is ... their password.

And you just might be surprised how widespread that is. (On your own system, "try it.")

To really secure your system, you need to: minimize the possible.

Linux_Kidd · 05-09-2012, 09:32 AM

Quote:

Originally Posted by sundialsvcs

Use PAM controls, not "sudoers."

There should be one, and only one, user on the system besides root that can become root, and that user should be a maintenance-user by some name which is e.g. responsible for maintaining all "local" software and files. If an ordinary user can do anything with elevated-privileges by any means then your system, I think, "is 'compromised' already."

For instance ... OS/X (and Linux, for that matter) users might crow about how "secure" their systems are, but if they can type sudo su and enter their own password (if they have one...) to get there, then the "root password" is ... their password.

And you just might be surprised how widespread that is. (On your own system, "try it.")

To really secure your system, you need to: minimize the possible.

ordinary users cant sudo, it would be %sysadmins or something like that, and that group would be strictly limited/monitored, etc.

%sysadmins ALL=(root) ALL
%oracle-nuts ALL=(oracle) ALL

chmod 500 /bin/su
chattr +i /bin/su