I'm trying to create a setuid Perl script (yes, I am aware about the security implications), but am getting this error:
% cat testsetuid.pl #!/usr/bin/perl -UT print "My real user id is $< but my effective user id is $>\n"; exit(0); % ./testsetuid.pl Can't do setuid (cannot exec sperl)
I am using the stock Perl that came with CentOS 4.5. The problem I am trying to solve is to run a software build as a particular user. We want any user to be able to submit a build job that runs on the build machine as the designated build user. If there is a better way to do this, I'm open to suggestions.
Alfred
On Fri, 2007-11-16 at 09:42 -0500, Alfred von Campe wrote:
I'm trying to create a setuid Perl script (yes, I am aware about the security implications), but am getting this error:
% cat testsetuid.pl #!/usr/bin/perl -UT print "My real user id is $< but my effective user id is $>\n"; exit(0); % ./testsetuid.pl Can't do setuid (cannot exec sperl)
I am using the stock Perl that came with CentOS 4.5. The problem I am trying to solve is to run a software build as a particular user. We want any user to be able to submit a build job that runs on the build machine as the designated build user. If there is a better way to do this, I'm open to suggestions.
Alfred
Being aware of the security implications, do you have perl-suidperl-X.rpm installed?
On 11/16/07, Marc Wiatrowski mwia@iglass.net wrote:
On Fri, 2007-11-16 at 09:42 -0500, Alfred von Campe wrote:
I'm trying to create a setuid Perl script (yes, I am aware about the security implications), but am getting this error:
% cat testsetuid.pl #!/usr/bin/perl -UT print "My real user id is $< but my effective user id is $>\n"; exit(0); % ./testsetuid.pl Can't do setuid (cannot exec sperl)
I am using the stock Perl that came with CentOS 4.5. The problem I am trying to solve is to run a software build as a particular user. We want any user to be able to submit a build job that runs on the build machine as the designated build user. If there is a better way to do this, I'm open to suggestions.
Alfred
Being aware of the security implications, do you have perl-suidperl-X.rpm installed?
Yeah, its actually the interpreter that is setuid, as the script doesn't actually execute per say, but its really "config" file for the interpreter, at least from the OS perspective...james perl-suidper-*.rpm contains the setuid interpreter...james
On Nov 16, 2007, at 9:55, Marc Wiatrowski wrote:
Being aware of the security implications, do you have perl-suidperl-X.rpm installed?
I meant I was aware of the implications of running setuid scripts. I was not aware that CentOS' upstream provider had packaged suidperl separately. Installing this package solved my problem. However, I am pursuing an sudo solution at the moment that may work even better for me.
Thanks, Alfred
On 11/16/07, Alfred von Campe alfred@von-campe.com wrote:
On Nov 16, 2007, at 9:55, Marc Wiatrowski wrote:
Being aware of the security implications, do you have perl-suidperl-X.rpm installed?
I meant I was aware of the implications of running setuid scripts. I was not aware that CentOS' upstream provider had packaged suidperl separately. Installing this package solved my problem. However, I am pursuing an sudo solution at the moment that may work even better for me.
setuid scripts are not by their nature bad as some would propose. As a matter of fact without using a system with mandetory access controls like SELinux, they can be effective tools to enhance overal security provided you follow some simple guidelines quite rigorously:
- As soon as you start de-elevate your privileges. - Only elevate your privileges for as long as you need to (as an example one may need root to open certain files, but once its opened you do not need root to read and write the file). - Try to keep the setuid program as simple as possible. If there is a point where it can throw away its privileges forever then do so. - Be very rigorous in determining that a user in the current context they are in should be using the setuid script.
I think the key word in alll that is "rigor" and though not used, "aware".
Cheers...james
Thanks, Alfred
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Nov 16, 2007 11:16 AM, James Olin Oden james.oden@gmail.com wrote:
On 11/16/07, Alfred von Campe alfred@von-campe.com wrote:
On Nov 16, 2007, at 9:55, Marc Wiatrowski wrote:
Being aware of the security implications, do you have perl-suidperl-X.rpm installed?
I meant I was aware of the implications of running setuid scripts. I was not aware that CentOS' upstream provider had packaged suidperl separately. Installing this package solved my problem. However, I am pursuing an sudo solution at the moment that may work even better for me.
setuid scripts are not by their nature bad as some would propose. As a matter of fact without using a system with mandetory access controls like SELinux, they can be effective tools to enhance overal security provided you follow some simple guidelines quite rigorously:
- As soon as you start de-elevate your privileges.
- Only elevate your privileges for as long as you need to (as an example one may need root to open certain files, but once its opened you do not need root to read and write the file).
- Try to keep the setuid program as simple as possible. If there
is a point where it can throw away its privileges forever then do so.
- Be very rigorous in determining that a user in the current
context they are in should be using the setuid script.
I think the key word in alll that is "rigor" and though not used, "aware".
Cheers...james
Good suggestions. Also keep in mind that you don't always suid to root. You can also suid to another user (which seems to be the case here).
Good suggestions. Also keep in mind that you don't always suid to root. You can also suid to another user (which seems to be the case here).
Sure. Just like login does.
Actually, want I would really like to see is the ability to mark certain sections of code to be ran as another user, but to do this marking at build time rather than using a elevation and de-elevation algorithm. This avoids the problem of someone being able to in non-elevated mode call elevate, as the code was immutabley marked at build time to run at whatever privilige level it was set too.
This is not UNIX's current model, and it might just be a half-brained idea, but it seems to me it would get past the major weaknesses of setuid programs.
Cheers...james
on 11/16/2007 7:56 AM Alfred von Campe spake the following:
On Nov 16, 2007, at 9:55, Marc Wiatrowski wrote:
Being aware of the security implications, do you have perl-suidperl-X.rpm installed?
I meant I was aware of the implications of running setuid scripts. I was not aware that CentOS' upstream provider had packaged suidperl separately. Installing this package solved my problem. However, I am pursuing an sudo solution at the moment that may work even better for me.
Thanks, Alfred
The security concerns are why it was packaged separately. A sysadmin needs to explicitly install it, so he/she should know it is there and watch for problems.
-
Alfred von Campe -
Brian Mathis -
James Olin Oden -
Marc Wiatrowski -
Scott Silva