From mhabib73 at gmail.com Tue Jul 6 20:52:36 2010 From: mhabib73 at gmail.com (Muhammad Habib) Date: Tue, 6 Jul 2010 20:52:36 -0400 Subject: [sudo-users] restrict shell out to root using sudo Message-ID: Hi, I am looking for restricting users to do shell out in their scripts. For example , I have script1 which I have given user "userA" to run using sudo e.g. sudo script1. and script is owned by root as well so user cannot update the script. However, user can edit with sudoedit as well. Now , if user modifies this script to call /bin/sh , he gets the root access when he runs the script i.e. "sudo script1". I tried to stop it using "NOEXEC" function but that will cause this script1 to run OK , but all commands in this script (eg. ps , uname etc.) will fail to run as well. script1 is as follows: ============================== #!/bin/ksh uname >> /tmp/myhost ps -ef | grep db >> /tmp/myproc /bin/sh =============================== Thanks Habib -- This communication contains confidential information intended only for the persons to whom it is addressed. Any other distribution, copying or disclosure is strictly prohibited. If you have received this communication in error, please notify the sender and delete this e-mail message immediately. Le pr?sent message contient des renseignements de nature confidentielle r?serv?s uniquement ? l'usage du destinataire. Toute diffusion, distribution, divulgation, utilisation ou reproduction de la pr?sente communication, et de tout fichier qui y est joint, est strictement interdite. Si vous avez re?u le pr?sent message ?lectronique par erreur, veuillez informer imm?diatement l'exp?diteur et supprimer le message de votre ordinateur et de votre serveur. From Todd.Miller at courtesan.com Wed Jul 7 15:46:42 2010 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Wed, 07 Jul 2010 15:46:42 -0400 Subject: [sudo-users] restrict shell out to root using sudo In-Reply-To: Your message of "Tue, 06 Jul 2010 20:52:36 EDT." References: Message-ID: <201007071946.o67JkgIs004866@core.courtesan.com> If you give the user the ability to edit a script they are allowed to run via sudo there's really no way to prevent them from running any command. - todd From highc at stny.rr.com Sat Jul 10 13:51:53 2010 From: highc at stny.rr.com (highc at stny.rr.com) Date: Sat, 10 Jul 2010 13:51:53 -0400 Subject: [sudo-users] restrict shell out to root using sudo In-Reply-To: References: Message-ID: <4C38B339.8010602@stny.rr.com> Muhammad Habib wrote: > Hi, > > I am looking for restricting users to do shell out in their scripts. [...] I tried to stop it using "NOEXEC" function but that > will cause this script1 to run OK , but all commands in this script (eg. ps > , uname etc.) will fail to run as well. > > script1 is as follows: > > ============================== > #!/bin/ksh > uname >> /tmp/myhost > ps -ef | grep db >> /tmp/myproc > > /bin/sh > > =============================== > > Thanks > > Habib > Todd's right, there's no way to stop someone from running arbitrary commands; however, you can consider instead authorizing them to run the commands withing the script; for instance... > ============================== #!/bin/ksh cp /tmp/myhost /tmp/$$.tmp uname >> /tmp/$$.tmp sudo cp /tmp/$$.tmp /tmp/myhost cp /tmp/myproc /tmp/$$.tmp ps -ef | grep db >> /tmp/$$.tmp sudo cp /tmp/$$.tmp /tmp/myproc rm /tmp/$$.tmp Then you authorize them to run sudo for cp, with as tight as possible definition, instead of the script. Modifiction of the script is less problematic since they can change 'details' around how the script can run, but cannot introduce any commands to run with root authority they are not already authorized to run. You may need to set the sudo authorization with 'NOPASSWD' for the command, depending on how long the script might run, etc. Of course, you still need to trust this person, as there's some very unpleasent things they can do with cp as allowed above; but it has to be less risk than allowing them to run arbitrary commands. I know we are using this as 'just an example', but it seems to me the simplest solution here is to assign the user to a group; and give that group write authority to /tmp/myhost and /tmp/myproc. For example, say someone wants to be able to take a snap shot of how full -all- file systems are, now and again. capturedf.ksh #!/bin/ksh sudo df -k > /tmp/$$.tmp date >> /tmp/collected.df cat /tmp/$$.tmp >> /tmp/collected.df # do some processing on the file /tmp/$$.tmp # For instance, send an alert if a filesystem is over 90% full. [...] rm /tmp/$$.tmp ===== You assign a particular group to be able to update /tmp/collected.df (presumably so someone debugging full file systems can see any historical data); the only thing in the script they need root authority for is 'df', so you authorize -that-. The rest of the invokation doesn't need root authority, so you don't have them run as root... much safer. (df can sometimes require root authority (or more authority than a particular user has) depending on the ownership/access rights on the mount points.) If they need to modify the script, it's not a big deal since all you really have done is give them the authority to run df. -- Good luck... Chris. From mhabib73 at gmail.com Sat Jul 10 23:20:38 2010 From: mhabib73 at gmail.com (Muhammad Habib) Date: Sat, 10 Jul 2010 23:20:38 -0400 Subject: [sudo-users] restrict shell out to root using sudo In-Reply-To: <4C38B339.8010602@stny.rr.com> References: <4C38B339.8010602@stny.rr.com> Message-ID: Hi Chris/Todd/Jackson, Thanks very much and I appreciate your valuable input. This will help me to finalize our sudo procedures and control for application team. Regards M.Habib On Sat, Jul 10, 2010 at 1:51 PM, wrote: > > > Muhammad Habib wrote: > >> Hi, >> >> I am looking for restricting users to do shell out in their scripts. [...] >> I tried to stop it using "NOEXEC" function but that >> >> will cause this script1 to run OK , but all commands in this script (eg. >> ps >> , uname etc.) will fail to run as well. >> >> script1 is as follows: >> >> ============================== >> #!/bin/ksh >> uname >> /tmp/myhost >> ps -ef | grep db >> /tmp/myproc >> >> /bin/sh >> >> =============================== >> >> Thanks >> >> Habib >> >> Todd's right, there's no way to stop someone from running arbitrary > commands; however, you can consider instead authorizing them to run the > commands withing the script; for instance... > > > ============================== > #!/bin/ksh > cp /tmp/myhost /tmp/$$.tmp > uname >> /tmp/$$.tmp > sudo cp /tmp/$$.tmp /tmp/myhost > cp /tmp/myproc /tmp/$$.tmp > ps -ef | grep db >> /tmp/$$.tmp > sudo cp /tmp/$$.tmp /tmp/myproc > rm /tmp/$$.tmp > Then you authorize them to run sudo for cp, with as tight as possible > definition, instead of the script. Modifiction of the script is less > problematic since they can change 'details' around how the script can run, > but cannot introduce any commands to run with root authority they are not > already authorized to run. You may need to set the sudo authorization with > 'NOPASSWD' for the command, depending on how long the script might run, etc. > > Of course, you still need to trust this person, as there's some very > unpleasent things they can do with cp as allowed above; but it has to be > less risk than allowing them to run arbitrary commands. > > I know we are using this as 'just an example', but it seems to me the > simplest solution here is to assign the user to a group; and give that group > write authority to /tmp/myhost and /tmp/myproc. > > For example, say someone wants to be able to take a snap shot of how full > -all- file systems are, now and again. > > capturedf.ksh > #!/bin/ksh > sudo df -k > /tmp/$$.tmp > date >> /tmp/collected.df > cat /tmp/$$.tmp >> /tmp/collected.df > # do some processing on the file /tmp/$$.tmp > # For instance, send an alert if a filesystem is over 90% full. > [...] > rm /tmp/$$.tmp > ===== > You assign a particular group to be able to update /tmp/collected.df > (presumably so someone debugging full file systems can see any historical > data); the only thing in the script they need root authority for is 'df', so > you authorize -that-. The rest of the invokation doesn't need root > authority, so you don't have them run as root... much safer. (df can > sometimes require root authority (or more authority than a particular user > has) depending on the ownership/access rights on the mount points.) If they > need to modify the script, it's not a big deal since all you really have > done is give them the authority to run df. > > -- > Good luck... Chris. > > > ____________________________________________________________ > sudo-users mailing list > For list information, options, or to unsubscribe, visit: > http://www.sudo.ws/mailman/listinfo/sudo-users > -- This communication contains confidential information intended only for the persons to whom it is addressed. Any other distribution, copying or disclosure is strictly prohibited. If you have received this communication in error, please notify the sender and delete this e-mail message immediately. Le pr?sent message contient des renseignements de nature confidentielle r?serv?s uniquement ? l'usage du destinataire. Toute diffusion, distribution, divulgation, utilisation ou reproduction de la pr?sente communication, et de tout fichier qui y est joint, est strictement interdite. Si vous avez re?u le pr?sent message ?lectronique par erreur, veuillez informer imm?diatement l'exp?diteur et supprimer le message de votre ordinateur et de votre serveur. From boomer at brainfood.homelinux.org Mon Jul 12 10:34:13 2010 From: boomer at brainfood.homelinux.org (Boomer Brainfood) Date: Mon, 12 Jul 2010 16:34:13 +0200 Subject: [sudo-users] sudoers and winbind Message-ID: Hello everybody, my company want's to integrate all Unix servers into active directory. For "normal" account management I decided more or less to go down the winbind route. To have all information in one place, we also want to put sudoers in the AD. Now the question is, how can I access the information ? I don't think, winbind can provide sudoers information. So, I guess I have to maintin a separate ldap.conf for sudo. But, how does sudo authenticate to the LDAP server (the user is authenticated using pam and thus through winbind (unless NOPASSWD is defined)) - somebody told me that AD doesn't support anonymous queries - if anonymous queries are possible, then sudoers becomes world-readable, which is different from the local filesystem Sincerely Bernhard -- Minds are like parachutes They only function when open From paul at cantle.me Mon Jul 12 11:41:20 2010 From: paul at cantle.me (Paul Cantle) Date: Mon, 12 Jul 2010 16:41:20 +0100 Subject: [sudo-users] sudoers and winbind In-Reply-To: References: Message-ID: Hi, This is my first post to this group so hope this helps. With regards to the AD integration: 1) I don't use winbind to integrate my Linux systems into AD (I use krb and LDAP) so can't really comment on that part of it :-( Sorry. 2) By default, Active Directory (not sure what version you're using (assuming 2003R2 or 2008)) does not allow anonymous queries. You can either change that or add this into /etc/ldap.conf host x.x.x.x url ldap://your_dc.fqdn (or ldaps:// if that's applicable). base dc=your,dc=domain,dc=com binddn user at your.domain.com bindpw PlainTxtPw I'd make that user a "noddy" account with minimum AD privs. (sorry if you're already doing this and I'm making out you don't know...it's not my intention). 3) With regards to the specific sudoers section - in /etc/ldap.conf sudoers_base ou=SUDOers,dc=your,dc=domain,dc=com 4) You'll need to convert your current (or a new) /etc/sudoers into ldif format using the scripts provided in the sudo distro (they're not perfect at this stage), then import it into your AD by running ldifde.exe on (one of) your Domain Controllers. 5) The NOPASSWD flag (in/etc/sudoers) is replaced with a "!authenticate" flag in one of the sudoOption: attributes for the relevant sudoRole:. On the flip-side "authenticate" is the same as the default of PASSWD which is also placed in one of the sudoOption: attributes. You will need to add the AD users/groups (using "username" or "%groupname") into the sudoUser: attribute in the relevant group to grant the permissions. To add additional users, groups, perms, etc into sudoers once it's in the AD. You can use ADUC as per normal AD management and then right click the groups in the SUDOers OU and then select the attributes you want to manage. Once you save, changes take effect straight away. Regardless of anonymous connections to the AD. Anyone on the system can read /etc/ldap.conf (well, if they want to use the features that it controls they'll need to), also, as all users are logged in via the AD anyway, by default, anyone could do an "ldapsearch", authenticate as themselves and then view the SUDOers attributes (not sure if there is a way to prevent this). So on that note, I don't know how you'd get the same perms as UNIX 400 root:root. Also, it's just worth noting that if your current /etc/sudoers uses command_aliases then they'll not import into the AD and actually work. You'll need to list the absolute commands in the sudoCommand: attributes (with the exception of the "ALL" alias, which works fine). I hope that helps a bit Paul ________________________________________ From: sudo-users-bounces at courtesan.com [sudo-users-bounces at courtesan.com] On Behalf Of Boomer Brainfood [boomer at brainfood.homelinux.org] Sent: 12 July 2010 15:34 To: sudo-users at sudo.ws Subject: [sudo-users] sudoers and winbind Hello everybody, my company want's to integrate all Unix servers into active directory. For "normal" account management I decided more or less to go down the winbind route. To have all information in one place, we also want to put sudoers in the AD. Now the question is, how can I access the information ? I don't think, winbind can provide sudoers information. So, I guess I have to maintin a separate ldap.conf for sudo. But, how does sudo authenticate to the LDAP server (the user is authenticated using pam and thus through winbind (unless NOPASSWD is defined)) - somebody told me that AD doesn't support anonymous queries - if anonymous queries are possible, then sudoers becomes world-readable, which is different from the local filesystem Sincerely Bernhard -- Minds are like parachutes They only function when open ____________________________________________________________ sudo-users mailing list For list information, options, or to unsubscribe, visit: http://www.sudo.ws/mailman/listinfo/sudo-users From paul at cantle.me Mon Jul 12 11:44:21 2010 From: paul at cantle.me (Paul Cantle) Date: Mon, 12 Jul 2010 16:44:21 +0100 Subject: [sudo-users] sudoers and winbind In-Reply-To: References: , Message-ID: Apologies url should be uri rgds Paul ________________________________________ From: sudo-users-bounces at courtesan.com [sudo-users-bounces at courtesan.com] On Behalf Of Paul Cantle [paul at cantle.me] Sent: 12 July 2010 16:41 To: Boomer Brainfood; sudo-users at sudo.ws Subject: Re: [sudo-users] sudoers and winbind Hi, This is my first post to this group so hope this helps. With regards to the AD integration: 1) I don't use winbind to integrate my Linux systems into AD (I use krb and LDAP) so can't really comment on that part of it :-( Sorry. 2) By default, Active Directory (not sure what version you're using (assuming 2003R2 or 2008)) does not allow anonymous queries. You can either change that or add this into /etc/ldap.conf host x.x.x.x url ldap://your_dc.fqdn (or ldaps:// if that's applicable). base dc=your,dc=domain,dc=com binddn user at your.domain.com bindpw PlainTxtPw I'd make that user a "noddy" account with minimum AD privs. (sorry if you're already doing this and I'm making out you don't know...it's not my intention). 3) With regards to the specific sudoers section - in /etc/ldap.conf sudoers_base ou=SUDOers,dc=your,dc=domain,dc=com 4) You'll need to convert your current (or a new) /etc/sudoers into ldif format using the scripts provided in the sudo distro (they're not perfect at this stage), then import it into your AD by running ldifde.exe on (one of) your Domain Controllers. 5) The NOPASSWD flag (in/etc/sudoers) is replaced with a "!authenticate" flag in one of the sudoOption: attributes for the relevant sudoRole:. On the flip-side "authenticate" is the same as the default of PASSWD which is also placed in one of the sudoOption: attributes. You will need to add the AD users/groups (using "username" or "%groupname") into the sudoUser: attribute in the relevant group to grant the permissions. To add additional users, groups, perms, etc into sudoers once it's in the AD. You can use ADUC as per normal AD management and then right click the groups in the SUDOers OU and then select the attributes you want to manage. Once you save, changes take effect straight away. Regardless of anonymous connections to the AD. Anyone on the system can read /etc/ldap.conf (well, if they want to use the features that it controls they'll need to), also, as all users are logged in via the AD anyway, by default, anyone could do an "ldapsearch", authenticate as themselves and then view the SUDOers attributes (not sure if there is a way to prevent this). So on that note, I don't know how you'd get the same perms as UNIX 400 root:root. Also, it's just worth noting that if your current /etc/sudoers uses command_aliases then they'll not import into the AD and actually work. You'll need to list the absolute commands in the sudoCommand: attributes (with the exception of the "ALL" alias, which works fine). I hope that helps a bit Paul ________________________________________ From: sudo-users-bounces at courtesan.com [sudo-users-bounces at courtesan.com] On Behalf Of Boomer Brainfood [boomer at brainfood.homelinux.org] Sent: 12 July 2010 15:34 To: sudo-users at sudo.ws Subject: [sudo-users] sudoers and winbind Hello everybody, my company want's to integrate all Unix servers into active directory. For "normal" account management I decided more or less to go down the winbind route. To have all information in one place, we also want to put sudoers in the AD. Now the question is, how can I access the information ? I don't think, winbind can provide sudoers information. So, I guess I have to maintin a separate ldap.conf for sudo. But, how does sudo authenticate to the LDAP server (the user is authenticated using pam and thus through winbind (unless NOPASSWD is defined)) - somebody told me that AD doesn't support anonymous queries - if anonymous queries are possible, then sudoers becomes world-readable, which is different from the local filesystem Sincerely Bernhard -- Minds are like parachutes They only function when open ____________________________________________________________ sudo-users mailing list For list information, options, or to unsubscribe, visit: http://www.sudo.ws/mailman/listinfo/sudo-users ____________________________________________________________ sudo-users mailing list For list information, options, or to unsubscribe, visit: http://www.sudo.ws/mailman/listinfo/sudo-users From boomer at brainfood.homelinux.org Tue Jul 13 03:32:28 2010 From: boomer at brainfood.homelinux.org (Boomer Brainfood) Date: Tue, 13 Jul 2010 09:32:28 +0200 Subject: [sudo-users] sudoers and winbind In-Reply-To: References: , Message-ID: Hi, thank you very much for your very interesting explanation. I will review it as soon as I have a test AD controller. Is using a proxy user the definitive solution ? I?d prefer anonymous queries over a proxy user. Sincerely Bernhard On Mon, July 12, 2010 17:44, Paul Cantle wrote: > Apologies > > url should be uri > > rgds > > Paul > ________________________________________ > From: sudo-users-bounces at courtesan.com [sudo-users-bounces at courtesan.com] > On Behalf Of Paul Cantle [paul at cantle.me] > Sent: 12 July 2010 16:41 > To: Boomer Brainfood; sudo-users at sudo.ws > Subject: Re: [sudo-users] sudoers and winbind > > Hi, > > This is my first post to this group so hope this helps. > > With regards to the AD integration: > > 1) I don't use winbind to integrate my Linux systems into AD (I use krb > and LDAP) so can't really comment on that part of it :-( Sorry. > > 2) By default, Active Directory (not sure what version you're using > (assuming 2003R2 or 2008)) does not allow anonymous queries. You can > either change that or add this into /etc/ldap.conf > > host x.x.x.x > url ldap://your_dc.fqdn (or ldaps:// if that's applicable). > base dc=your,dc=domain,dc=com > binddn user at your.domain.com > bindpw PlainTxtPw > > I'd make that user a "noddy" account with minimum AD privs. (sorry if > you're already doing this and I'm making out you don't know...it's not my > intention). > > 3) With regards to the specific sudoers section - in /etc/ldap.conf > > sudoers_base ou=SUDOers,dc=your,dc=domain,dc=com > > 4) You'll need to convert your current (or a new) /etc/sudoers into ldif > format using the scripts provided in the sudo distro (they're not perfect > at this stage), then import it into your AD by running ldifde.exe on (one > of) your Domain Controllers. > > 5) The NOPASSWD flag (in/etc/sudoers) is replaced with a "!authenticate" > flag in one of the sudoOption: attributes for the relevant sudoRole:. On > the flip-side "authenticate" is the same as the default of PASSWD which is > also placed in one of the sudoOption: attributes. > > You will need to add the AD users/groups (using "username" or > "%groupname") into the sudoUser: attribute in the relevant group to grant > the permissions. To add additional users, groups, perms, etc into sudoers > once it's in the AD. You can use ADUC as per normal AD management and then > right click the groups in the SUDOers OU and then select the attributes > you want to manage. Once you save, changes take effect straight away. > > Regardless of anonymous connections to the AD. Anyone on the system can > read /etc/ldap.conf (well, if they want to use the features that it > controls they'll need to), also, as all users are logged in via the AD > anyway, by default, anyone could do an "ldapsearch", authenticate as > themselves and then view the SUDOers attributes (not sure if there is a > way to prevent this). So on that note, I don't know how you'd get the same > perms as UNIX 400 root:root. > > Also, it's just worth noting that if your current /etc/sudoers uses > command_aliases then they'll not import into the AD and actually work. > You'll need to list the absolute commands in the sudoCommand: attributes > (with the exception of the "ALL" alias, which works fine). > > I hope that helps a bit > > Paul > > ________________________________________ > From: sudo-users-bounces at courtesan.com [sudo-users-bounces at courtesan.com] > On Behalf Of Boomer Brainfood [boomer at brainfood.homelinux.org] > Sent: 12 July 2010 15:34 > To: sudo-users at sudo.ws > Subject: [sudo-users] sudoers and winbind > > Hello everybody, > > my company want's to integrate all Unix servers into active directory. > For "normal" account management I decided more or less to go down the > winbind route. > To have all information in one place, we also want to put sudoers in the > AD. > Now the question is, how can I access the information ? > I don't think, winbind can provide sudoers information. > So, I guess I have to maintin a separate ldap.conf for sudo. > But, how does sudo authenticate to the LDAP server (the user is > authenticated using pam and thus through winbind (unless NOPASSWD is > defined)) > - somebody told me that AD doesn't support anonymous queries > - if anonymous queries are possible, then sudoers becomes world-readable, > which is different from the local filesystem > > Sincerely > Bernhard > > > > -- > Minds are like parachutes > They only function when open > > ____________________________________________________________ > sudo-users mailing list > For list information, options, or to unsubscribe, visit: > http://www.sudo.ws/mailman/listinfo/sudo-users > ____________________________________________________________ > sudo-users mailing list > For list information, options, or to unsubscribe, visit: > http://www.sudo.ws/mailman/listinfo/sudo-users > -- When did I realize I was God? Well, I was praying and I suddenly realized I was talking to myself. From paul at cantle.me Tue Jul 13 06:12:25 2010 From: paul at cantle.me (Paul Cantle) Date: Tue, 13 Jul 2010 11:12:25 +0100 Subject: [sudo-users] sudoers and winbind In-Reply-To: References: , Message-ID: Hi, If you want to browse the AD anonymously, then this article explaining how to use ADSIEdit will probably help - http://support.microsoft.com/kb/320528 Regards Paul -----Original Message----- From: Boomer Brainfood [mailto:boomer at brainfood.homelinux.org] Sent: 13 July 2010 08:32 To: Paul Cantle Cc: sudo-users at sudo.ws Subject: RE: [sudo-users] sudoers and winbind Hi, thank you very much for your very interesting explanation. I will review it as soon as I have a test AD controller. Is using a proxy user the definitive solution ? I'd prefer anonymous queries over a proxy user. Sincerely Bernhard On Mon, July 12, 2010 17:44, Paul Cantle wrote: > Apologies > > url should be uri > > rgds > > Paul > ________________________________________ > From: sudo-users-bounces at courtesan.com > [sudo-users-bounces at courtesan.com] > On Behalf Of Paul Cantle [paul at cantle.me] > Sent: 12 July 2010 16:41 > To: Boomer Brainfood; sudo-users at sudo.ws > Subject: Re: [sudo-users] sudoers and winbind > > Hi, > > This is my first post to this group so hope this helps. > > With regards to the AD integration: > > 1) I don't use winbind to integrate my Linux systems into AD (I use > krb and LDAP) so can't really comment on that part of it :-( Sorry. > > 2) By default, Active Directory (not sure what version you're using > (assuming 2003R2 or 2008)) does not allow anonymous queries. You can > either change that or add this into /etc/ldap.conf > > host x.x.x.x > url ldap://your_dc.fqdn (or ldaps:// if that's applicable). > base dc=your,dc=domain,dc=com > binddn user at your.domain.com > bindpw PlainTxtPw > > I'd make that user a "noddy" account with minimum AD privs. (sorry if > you're already doing this and I'm making out you don't know...it's not > my intention). > > 3) With regards to the specific sudoers section - in /etc/ldap.conf > > sudoers_base ou=SUDOers,dc=your,dc=domain,dc=com > > 4) You'll need to convert your current (or a new) /etc/sudoers into > ldif format using the scripts provided in the sudo distro (they're not > perfect at this stage), then import it into your AD by running > ldifde.exe on (one > of) your Domain Controllers. > > 5) The NOPASSWD flag (in/etc/sudoers) is replaced with a "!authenticate" > flag in one of the sudoOption: attributes for the relevant sudoRole:. > On the flip-side "authenticate" is the same as the default of PASSWD > which is also placed in one of the sudoOption: attributes. > > You will need to add the AD users/groups (using "username" or > "%groupname") into the sudoUser: attribute in the relevant group to > grant the permissions. To add additional users, groups, perms, etc > into sudoers once it's in the AD. You can use ADUC as per normal AD > management and then right click the groups in the SUDOers OU and then > select the attributes you want to manage. Once you save, changes take effect straight away. > > Regardless of anonymous connections to the AD. Anyone on the system > can read /etc/ldap.conf (well, if they want to use the features that > it controls they'll need to), also, as all users are logged in via the > AD anyway, by default, anyone could do an "ldapsearch", authenticate > as themselves and then view the SUDOers attributes (not sure if there > is a way to prevent this). So on that note, I don't know how you'd get > the same perms as UNIX 400 root:root. > > Also, it's just worth noting that if your current /etc/sudoers uses > command_aliases then they'll not import into the AD and actually work. > You'll need to list the absolute commands in the sudoCommand: > attributes (with the exception of the "ALL" alias, which works fine). > > I hope that helps a bit > > Paul > > ________________________________________ > From: sudo-users-bounces at courtesan.com > [sudo-users-bounces at courtesan.com] > On Behalf Of Boomer Brainfood [boomer at brainfood.homelinux.org] > Sent: 12 July 2010 15:34 > To: sudo-users at sudo.ws > Subject: [sudo-users] sudoers and winbind > > Hello everybody, > > my company want's to integrate all Unix servers into active directory. > For "normal" account management I decided more or less to go down the > winbind route. > To have all information in one place, we also want to put sudoers in > the AD. > Now the question is, how can I access the information ? > I don't think, winbind can provide sudoers information. > So, I guess I have to maintin a separate ldap.conf for sudo. > But, how does sudo authenticate to the LDAP server (the user is > authenticated using pam and thus through winbind (unless NOPASSWD is > defined)) > - somebody told me that AD doesn't support anonymous queries > - if anonymous queries are possible, then sudoers becomes > world-readable, which is different from the local filesystem > > Sincerely > Bernhard > > > > -- > Minds are like parachutes > They only function when open > > ____________________________________________________________ > sudo-users mailing list For list information, > options, or to unsubscribe, visit: > http://www.sudo.ws/mailman/listinfo/sudo-users > ____________________________________________________________ > sudo-users mailing list For list information, > options, or to unsubscribe, visit: > http://www.sudo.ws/mailman/listinfo/sudo-users > -- When did I realize I was God? Well, I was praying and I suddenly realized I was talking to myself. From Matthew.Stier at us.fujitsu.com Tue Jul 13 07:59:32 2010 From: Matthew.Stier at us.fujitsu.com (Stier, Matthew) Date: Tue, 13 Jul 2010 06:59:32 -0500 Subject: [sudo-users] sudoers and winbind In-Reply-To: References: , Message-ID: <63F73C973E3E4547979026ECC295EF5C02D6796E@rchemxp01.fnc.net.local> It's simple enough to setup OpenLDAP as a relay between anonymous and proxyuser. I originally setup the OpenLDAP as a meta-ldap server; returning the results from searches of three directory servers (corporate and two engineering servers) to Unix e-mail clients, and various network devices. Now with e-mail consolidated at the corporate level, it is simply a bridge between the clients and devices expecting anonymous access, and the corporate AD server, expecting proxy user. PS: What devices? Our multi-function printer/copiers also scan to e-mail. The MFP are configured to use the OpenLDAP servers as a Network Addressbook. -----Original Message----- From: sudo-users-bounces at courtesan.com [mailto:sudo-users-bounces at courtesan.com] On Behalf Of Paul Cantle Sent: Tuesday, July 13, 2010 6:12 AM To: Boomer Brainfood Cc: sudo-users at sudo.ws Subject: Re: [sudo-users] sudoers and winbind Hi, If you want to browse the AD anonymously, then this article explaining how to use ADSIEdit will probably help - http://support.microsoft.com/kb/320528 Regards Paul -----Original Message----- From: Boomer Brainfood [mailto:boomer at brainfood.homelinux.org] Sent: 13 July 2010 08:32 To: Paul Cantle Cc: sudo-users at sudo.ws Subject: RE: [sudo-users] sudoers and winbind Hi, thank you very much for your very interesting explanation. I will review it as soon as I have a test AD controller. Is using a proxy user the definitive solution ? I'd prefer anonymous queries over a proxy user. Sincerely Bernhard On Mon, July 12, 2010 17:44, Paul Cantle wrote: > Apologies > > url should be uri > > rgds > > Paul > ________________________________________ > From: sudo-users-bounces at courtesan.com > [sudo-users-bounces at courtesan.com] > On Behalf Of Paul Cantle [paul at cantle.me] > Sent: 12 July 2010 16:41 > To: Boomer Brainfood; sudo-users at sudo.ws > Subject: Re: [sudo-users] sudoers and winbind > > Hi, > > This is my first post to this group so hope this helps. > > With regards to the AD integration: > > 1) I don't use winbind to integrate my Linux systems into AD (I use > krb and LDAP) so can't really comment on that part of it :-( Sorry. > > 2) By default, Active Directory (not sure what version you're using > (assuming 2003R2 or 2008)) does not allow anonymous queries. You can > either change that or add this into /etc/ldap.conf > > host x.x.x.x > url ldap://your_dc.fqdn (or ldaps:// if that's applicable). > base dc=your,dc=domain,dc=com > binddn user at your.domain.com > bindpw PlainTxtPw > > I'd make that user a "noddy" account with minimum AD privs. (sorry if > you're already doing this and I'm making out you don't know...it's not > my intention). > > 3) With regards to the specific sudoers section - in /etc/ldap.conf > > sudoers_base ou=SUDOers,dc=your,dc=domain,dc=com > > 4) You'll need to convert your current (or a new) /etc/sudoers into > ldif format using the scripts provided in the sudo distro (they're not > perfect at this stage), then import it into your AD by running > ldifde.exe on (one > of) your Domain Controllers. > > 5) The NOPASSWD flag (in/etc/sudoers) is replaced with a "!authenticate" > flag in one of the sudoOption: attributes for the relevant sudoRole:. > On the flip-side "authenticate" is the same as the default of PASSWD > which is also placed in one of the sudoOption: attributes. > > You will need to add the AD users/groups (using "username" or > "%groupname") into the sudoUser: attribute in the relevant group to > grant the permissions. To add additional users, groups, perms, etc > into sudoers once it's in the AD. You can use ADUC as per normal AD > management and then right click the groups in the SUDOers OU and then > select the attributes you want to manage. Once you save, changes take effect straight away. > > Regardless of anonymous connections to the AD. Anyone on the system > can read /etc/ldap.conf (well, if they want to use the features that > it controls they'll need to), also, as all users are logged in via the > AD anyway, by default, anyone could do an "ldapsearch", authenticate > as themselves and then view the SUDOers attributes (not sure if there > is a way to prevent this). So on that note, I don't know how you'd get > the same perms as UNIX 400 root:root. > > Also, it's just worth noting that if your current /etc/sudoers uses > command_aliases then they'll not import into the AD and actually work. > You'll need to list the absolute commands in the sudoCommand: > attributes (with the exception of the "ALL" alias, which works fine). > > I hope that helps a bit > > Paul > > ________________________________________ > From: sudo-users-bounces at courtesan.com > [sudo-users-bounces at courtesan.com] > On Behalf Of Boomer Brainfood [boomer at brainfood.homelinux.org] > Sent: 12 July 2010 15:34 > To: sudo-users at sudo.ws > Subject: [sudo-users] sudoers and winbind > > Hello everybody, > > my company want's to integrate all Unix servers into active directory. > For "normal" account management I decided more or less to go down the > winbind route. > To have all information in one place, we also want to put sudoers in > the AD. > Now the question is, how can I access the information ? > I don't think, winbind can provide sudoers information. > So, I guess I have to maintin a separate ldap.conf for sudo. > But, how does sudo authenticate to the LDAP server (the user is > authenticated using pam and thus through winbind (unless NOPASSWD is > defined)) > - somebody told me that AD doesn't support anonymous queries > - if anonymous queries are possible, then sudoers becomes > world-readable, which is different from the local filesystem > > Sincerely > Bernhard > > > > -- > Minds are like parachutes > They only function when open > > ____________________________________________________________ > sudo-users mailing list For list information, > options, or to unsubscribe, visit: > http://www.sudo.ws/mailman/listinfo/sudo-users > ____________________________________________________________ > sudo-users mailing list For list information, > options, or to unsubscribe, visit: > http://www.sudo.ws/mailman/listinfo/sudo-users > -- When did I realize I was God? Well, I was praying and I suddenly realized I was talking to myself. ____________________________________________________________ sudo-users mailing list For list information, options, or to unsubscribe, visit: http://www.sudo.ws/mailman/listinfo/sudo-users From poonaatsoc at gmail.com Tue Jul 20 07:01:44 2010 From: poonaatsoc at gmail.com (Anoop Saldanha) Date: Tue, 20 Jul 2010 16:31:44 +0530 Subject: [sudo-users] sudo not prompting for password across different sessions Message-ID: Hi. I am running 2 versions of slackware. 12 and 13.1. In both the boxes, if I open a terminal session, and type sudo ls /root it would ask me for a password. I enter the password and I get the ls results. Immediately I open a fresh(new) terminal and I again type sudo ls /root. But this time it doesn't ask me for a password. For every new session shouldn't sudo ask me for a password? As in, isn't sudo for one session specific to that session. I checked with a couple of my friends running ubuntu and some others on irc, and for them sudo doesn't mix sessions(it asks for a new password in a different session). My sudoers file root ALL=(ALL) ALL poona ALL=(ALL) ALL -- Regards, Anoop Saldanha From Todd.Miller at courtesan.com Tue Jul 20 07:27:47 2010 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Tue, 20 Jul 2010 07:27:47 -0400 Subject: [sudo-users] sudo not prompting for password across different sessions In-Reply-To: Your message of "Tue, 20 Jul 2010 16:31:44 +0530." References: Message-ID: <201007201127.o6KBRlJw017750@core.courtesan.com> In message so spake Anoop Saldanha (poonaatsoc): > I am running 2 versions of slackware. 12 and 13.1. In both the boxes, if I > open a terminal session, and type > > sudo ls /root > > it would ask me for a password. I enter the password and I get the ls > results. Immediately I open a fresh(new) terminal and I again type sudo ls > /root. But this time it doesn't ask me for a password. > > For every new session shouldn't sudo ask me for a password? As in, isn't > sudo for one session specific to that session. By default, sudo uses a single time stamp file per user. You can make that per-tty with a line like this in sudoers: Defaults tty_tickets - todd From poonaatsoc at gmail.com Tue Jul 20 11:44:12 2010 From: poonaatsoc at gmail.com (Anoop Saldanha) Date: Tue, 20 Jul 2010 21:14:12 +0530 Subject: [sudo-users] sudo not prompting for password across different sessions In-Reply-To: <201007201127.o6KBRlJw017750@core.courtesan.com> References: <201007201127.o6KBRlJw017750@core.courtesan.com> Message-ID: On Tue, Jul 20, 2010 at 4:57 PM, Todd C. Miller wrote: > In message > so spake Anoop Saldanha (poonaatsoc): > > > I am running 2 versions of slackware. 12 and 13.1. In both the boxes, > if I > > open a terminal session, and type > > > > sudo ls /root > > > > it would ask me for a password. I enter the password and I get the ls > > results. Immediately I open a fresh(new) terminal and I again type sudo > ls > > /root. But this time it doesn't ask me for a password. > > > > For every new session shouldn't sudo ask me for a password? As in, isn't > > sudo for one session specific to that session. > > By default, sudo uses a single time stamp file per user. You can > make that per-tty with a line like this in sudoers: > > Defaults tty_tickets > > - todd > Works now. Thanks -- Regards, Anoop Saldanha From petr.uzel at suse.cz Wed Jul 21 08:58:22 2010 From: petr.uzel at suse.cz (Petr Uzel) Date: Wed, 21 Jul 2010 14:58:22 +0200 Subject: [sudo-users] using localhost in sudoers Message-ID: <20100721125822.GA26326@foxbat.suse.cz> Hi all, How does "localhost" as Host_Alias in /etc/sudoers work? E.g. gentoo sudo(ers) guide [1] states that the rule swift localhost = /usr/bin/emerge allows running emerge only if the user swift is logged in locally, i.e. not through SSH. I don't think this is correct. AFAIU, the Host_Alias can not be used to differentiate between users logged in locally and through ssh, but only to restrict the rule to apply on machines where 'hostname'=='Host_Alias' (useful if sudoers file is shared across several machines). So, how is it? I presume I'm not the first one to ask this question, but I wasn't able to find any authoritative answer. [1] http://www.gentoo.org/doc/en/sudo-guide.xml Thanks in advance, Petr -- Petr Uzel IRC: ptr_uzl @ freenode -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From Todd.Miller at courtesan.com Wed Jul 21 09:27:30 2010 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Wed, 21 Jul 2010 09:27:30 -0400 Subject: [sudo-users] using localhost in sudoers In-Reply-To: Your message of "Wed, 21 Jul 2010 14:58:22 +0200." <20100721125822.GA26326@foxbat.suse.cz> References: <20100721125822.GA26326@foxbat.suse.cz> Message-ID: <201007211327.o6LDRU4W003936@core.courtesan.com> In message <20100721125822.GA26326 at foxbat.suse.cz> so spake Petr Uzel (petr.uzel): > How does "localhost" as Host_Alias in /etc/sudoers work? > > E.g. gentoo sudo(ers) guide [1] states that the rule > > swift localhost = /usr/bin/emerge > allows running emerge only if the user swift is logged in locally, > i.e. not through SSH. I don't think this is correct. AFAIU, the > Host_Alias can not be used to differentiate between users logged > in locally and through ssh, but only to restrict the rule to apply > on machines where 'hostname'=='Host_Alias' (useful if sudoers file > is shared across several machines). Unless the gentoo sudo contains changes to support this, "localhost" will never match as a hostname in sudoers unless the call to gethostname() fails. - todd From petr.uzel at suse.cz Wed Jul 21 09:39:34 2010 From: petr.uzel at suse.cz (Petr Uzel) Date: Wed, 21 Jul 2010 15:39:34 +0200 Subject: [sudo-users] using localhost in sudoers In-Reply-To: <201007211327.o6LDRU4W003936@core.courtesan.com> References: <20100721125822.GA26326@foxbat.suse.cz> <201007211327.o6LDRU4W003936@core.courtesan.com> Message-ID: <20100721133934.GA23899@foxbat.suse.cz> On Wed, Jul 21, 2010 at 09:27:30AM -0400, Todd C. Miller wrote: > In message <20100721125822.GA26326 at foxbat.suse.cz> > so spake Petr Uzel (petr.uzel): > > > How does "localhost" as Host_Alias in /etc/sudoers work? > > > > E.g. gentoo sudo(ers) guide [1] states that the rule > > > > swift localhost = /usr/bin/emerge > > > allows running emerge only if the user swift is logged in locally, > > i.e. not through SSH. I don't think this is correct. AFAIU, the > > Host_Alias can not be used to differentiate between users logged > > in locally and through ssh, but only to restrict the rule to apply > > on machines where 'hostname'=='Host_Alias' (useful if sudoers file > > is shared across several machines). > > Unless the gentoo sudo contains changes to support this, "localhost" > will never match as a hostname in sudoers unless the call to > gethostname() fails. Todd, thanks for the reply. I'm curious: is it somehow possible to restrict some of the rules only to users logged locally? Next, I think that the above is a common misunderstanding - maybe it should be mentioned in sudoers(5) and/or sudo FAQ ? Thanks, Petr -- Petr Uzel IRC: ptr_uzl @ freenode -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From Todd.Miller at courtesan.com Wed Jul 21 09:58:50 2010 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Wed, 21 Jul 2010 09:58:50 -0400 Subject: [sudo-users] using localhost in sudoers In-Reply-To: Your message of "Wed, 21 Jul 2010 15:39:34 +0200." <20100721133934.GA23899@foxbat.suse.cz> References: <20100721125822.GA26326@foxbat.suse.cz> <201007211327.o6LDRU4W003936@core.courtesan.com><20100721133934.GA23899@foxbat.suse.cz> Message-ID: <201007211358.o6LDwonq005504@core.courtesan.com> In message <20100721133934.GA23899 at foxbat.suse.cz> so spake Petr Uzel (petr.uzel): > I'm curious: is it somehow possible to restrict some of the rules only > to users logged locally? What would you consider a local user? If the user is logged in on /dev/console or a virtual console tty this is easy to determine but that's not the case for users logged in via a graphical login. > Next, I think that the above is a common misunderstanding - maybe > it should be mentioned in sudoers(5) and/or sudo FAQ ? I'm not sure where this misconception comes from but I can add something to the documentation to try and clear it up. - todd From petr.uzel at suse.cz Thu Jul 22 05:24:51 2010 From: petr.uzel at suse.cz (Petr Uzel) Date: Thu, 22 Jul 2010 11:24:51 +0200 Subject: [sudo-users] using localhost in sudoers In-Reply-To: <201007211358.o6LDwonq005504@core.courtesan.com> References: <20100721125822.GA26326@foxbat.suse.cz> <201007211327.o6LDRU4W003936@core.courtesan.com> <20100721133934.GA23899@foxbat.suse.cz> <201007211358.o6LDwonq005504@core.courtesan.com> Message-ID: <20100722092451.GA6540@foxbat.suse.cz> On Wed, Jul 21, 2010 at 09:58:50AM -0400, Todd C. Miller wrote: > In message <20100721133934.GA23899 at foxbat.suse.cz> > so spake Petr Uzel (petr.uzel): > > > I'm curious: is it somehow possible to restrict some of the rules only > > to users logged locally? > > What would you consider a local user? The same as who/lastlog commands. > If the user is logged in on > /dev/console or a virtual console tty this is easy to determine but > that's not the case for users logged in via a graphical login. I see. Only wtmp/utmp database comes to my mind. However, I don't know if this might work and I doubt it is worth it. As I said - I was just curious. > > Next, I think that the above is a common misunderstanding - maybe > > it should be mentioned in sudoers(5) and/or sudo FAQ ? > > I'm not sure where this misconception comes from but I can add > something to the documentation to try and clear it up. Thanks. > > - todd Petr -- Petr Uzel IRC: ptr_uzl @ freenode -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mindbuster31 at gmail.com Tue Jul 27 17:17:15 2010 From: mindbuster31 at gmail.com (Karthik S) Date: Tue, 27 Jul 2010 15:17:15 -0600 Subject: [sudo-users] Regarding SUDO behaviour change with environment variable handling in RedHat 5 Message-ID: Hi Experts, I have a biig clarification to make with respect to the BUZZ that is on, stating a massive behavioural change in the way SUDO's environment acts on the variables defined in it; in RedHat 5. I am in the process of handling the SUDO changes for a framework of applications from R4 to R5 and i need to know what changes are actually prominent with respect to env var in both the OS's, so that i can pick them up and handle them. Also i see that sudo -V is different from R4 in R5. Furthermore, i heard from folks that SUDO in R5 is scrubbing the environment before the execution of a command. People that i met here say that it is better to write wrapper scripts for a particular application so that we can define and export env var's for that specific application by sudo'ing the wrapper. This seems a feaasible option, but I REALLY NEED TO KNOW WHAT HAS CHANGED from the env variable perspective that we are having to seek alternate solutions to handle the messed up SUDO env. Any help will be reaaaaaaaally useful and will help take my implementation gracefully. I feel : if not aware, seek help, do it and learn it the right way, than just do it for the heck of it. Thanks Experts, Karthick From Todd.Miller at courtesan.com Tue Jul 27 18:07:33 2010 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Tue, 27 Jul 2010 18:07:33 -0400 Subject: [sudo-users] Regarding SUDO behaviour change with environment variable handling in RedHat 5 In-Reply-To: Your message of "Tue, 27 Jul 2010 15:17:15 MDT." References: Message-ID: <201007272207.o6RM7XDq016667@core.courtesan.com> Starting with sudo 1.6.9, the env_reset sudoers option is enabled by default. Many vendors, including RedHat, had enabled it prior to sudo 1.6.9 in the /etc/sudoers files they ship with their systems. Below is an excerpt from the sudo UPGRADE file: Environment variable handling has changed significantly in sudo 1.6.9. Prior to version 1.6.9, sudo would preserve the user's environment, pruning out potentially dangerous variables. Beginning with sudo 1.6.9, the envionment is reset to a default set of values with only a small number of "safe" variables preserved. To preserve specific environment variables, add them to the "env_keep" list in sudoers. E.g. Defaults env_keep += "EDITOR" The old behavior can be restored by negating the "env_reset" option in sudoers. E.g. Defaults !env_reset There have also been changes to how the "env_keep" and "env_check" options behave. Prior to sudo 1.6.9, the TERM and PATH environment variables would always be preserved even if the env_keep option was redefined. That is no longer the case. Consequently, if env_keep is set with "=" and not simply appended to (i.e. using "+="), PATH and TERM must be explicitly included in the list of environment variables to keep. The LOGNAME, SHELL, USER, and USERNAME environment variables are still always set. Additionally, the env_check setting previously had no effect when env_reset was set (which is now on by default). Starting with sudo 1.6.9, environment variables listed in env_check are also preserved in the env_reset case, provided that they do not contain a '/' or '%' character. Note that it is not necessary to also list a variable in env_keep--having it in env_check is sufficent. The default lists of variables to be preserved and/or checked are displayed when sudo is run by root with the -V flag. From jhammerman at videoegg.com Thu Jul 29 18:04:42 2010 From: jhammerman at videoegg.com (Joseph Hammerman) Date: Thu, 29 Jul 2010 15:04:42 -0700 Subject: [sudo-users] Unable to sudo following centos5.3 to centos5.5 upgrade In-Reply-To: <1939748856.61280440932454.JavaMail.josephhammerman@matchlessrunner.local> Message-ID: <273265625.81280441081547.JavaMail.josephhammerman@matchlessrunner.local> Good afternoon sudo users list: We recently upgraded from centos5.3 to centos5.5, which involved an upgrade of the sudo rpm from sudo-1.6.9p17-3.el5_3.1.x86_64.rpm to sudo-1.7.2p1-7.el5_5.x86_64.rpm When we attempt to sudo on the host following the upgrade we get the following error message: [root at studio101.sacpa ~]# sudo -l sudo: unable to cache group QA, already exists Has anyone else experienced anything similar to this? Does anyone have troubleshooting tips? I can attach our sudoers file if it would be helpful. Thanks!