Re: suid-perl going away?
Marc Haber wrote: What is the current recommended way to run perl scripts suid? Ever since that warning was added to perl-suid, many years ago, I've been writing my own suid wrappers for perl scripts in C. Why is perl-suid going away, and how am I supposed to replace its functionality? Well, it has a history of security holes, many of which can be attributed to it trying to be a general purpose suid wrapper to a language with a fairly complex external interface. Nice thing about writing a special-purpose wrapper instead is it's much easier to verify that it's secure. Of course the downside is that only people capable of writing secure C code need apply.. -- see shy jo signature.asc Description: Digital signature
Re: suid-perl going away?
On Thu, 23 Aug 2007 13:26:10 -0400, Joey Hess [EMAIL PROTECTED] wrote: Of course the downside is that only people capable of writing secure C code need apply.. Yes. I am not one of these. Which is why I chose a script language. I find the idea of removing an existing and working tool quite disturbing. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: suid-perl
According to Michael Stone: Quoting Wichert Akkerman ([EMAIL PROTECTED]): What perl-suid should do is check the mountoptions for the filesystem on which the script resides and abort if that was mounted with nosuid. Should be quite simple actually.. But that's still not general enough. For example, you just missed the case of noexec... The solution should be done at a higher level, IMHO... Every OS has a different set of mount options that may or may not be relevant to setuid security. I don't see what 'higher level' would be useful. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] When do you work? Whenever I'm not busy.
Re: suid-perl
Quoting Chip Salzenberg ([EMAIL PROTECTED]): According to Michael Stone: Quoting Wichert Akkerman ([EMAIL PROTECTED]): What perl-suid should do is check the mountoptions for the filesystem on which the script resides and abort if that was mounted with nosuid. Should be quite simple actually.. But that's still not general enough. For example, you just missed the case of noexec... The solution should be done at a higher level, IMHO... Every OS has a different set of mount options that may or may not be relevant to setuid security. I don't see what 'higher level' would be useful. Well, maybe I'm not clear on what you/wichert would do instead. How are you going to check this? Mike Stone
Re: suid-perl
On Sun, 31 Jan 1999, Chip Salzenberg wrote: According to Michael Stone: Quoting Wichert Akkerman ([EMAIL PROTECTED]): What perl-suid should do is check the mountoptions for the filesystem on which the script resides and abort if that was mounted with nosuid. Should be quite simple actually.. But that's still not general enough. For example, you just missed the case of noexec... The solution should be done at a higher level, IMHO... Every OS has a different set of mount options that may or may not be relevant to setuid security. I don't see what 'higher level' would be useful. The correct solution to this, surely, is for the mount nosuid to actually strip the suid bits of any files. So that any calls to stat() on a floppy simply won't see suid bits. I honestly can't see why the fs driver doesn't use this approach currently - seems the simplest and most consistent to me. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: suid-perl
According to Michael Stone: Quoting Chip Salzenberg ([EMAIL PROTECTED]): According to Michael Stone: Quoting Wichert Akkerman ([EMAIL PROTECTED]): What perl-suid should do is check the mountoptions for the filesystem on which the script resides and abort if that was mounted with nosuid. Should be quite simple actually.. But that's still not general enough. For example, you just missed the case of noexec... The solution should be done at a higher level, IMHO... Every OS has a different set of mount options that may or may not be relevant to setuid security. I don't see what 'higher level' would be useful. Well, maybe I'm not clear on what you/wichert would do instead. How are you going to check this? The code exists to check the mount options relevant to an open file. It's just a Small Matter of Programming to integrate that into the Perl source code, and disable emultation of setuid scripts when the 'nosuid' mount option is set. And as for 'noexec', well, it's not relevant to Perl anyway. (All you have to do is run perl scriptname instead of just ./scriptname.) Or do you suggest that every single language compiler/interpreter must check mount options? Should Java .class files be unusable if they're on a 'noexec' filesystem? I don't _think_ so. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] When do you work? Whenever I'm not busy.
Re: suid-perl
On Sun, 31 Jan 1999, Chip Salzenberg wrote: The code exists to check the mount options relevant to an open file. It's just a Small Matter of Programming to integrate that into the Perl source code, and disable emultation of setuid scripts when the 'nosuid' mount option is set. But, then every interpreter should do this (by analogy with you point below). Well, not a perfect analogy. But every suid-emulating interpreted. (Aside: Why hasn't linus patched the kernel so that suid scripts are secure? It's an easy task, surely?) And as for 'noexec', well, it's not relevant to Perl anyway. (All you have to do is run perl scriptname instead of just ./scriptname.) Or do you suggest that every single language compiler/interpreter must check mount options? Should Java .class files be unusable if they're on a 'noexec' filesystem? I don't _think_ so. As it is, noexec is almost useless. I can't help thinking that *all* interpreters *should* check noexec status. However, they don't.. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: suid-perl
According to Jules Bean: On Sun, 31 Jan 1999, Chip Salzenberg wrote: The code exists to check the mount options relevant to an open file. It's just a Small Matter of Programming to integrate that into the Perl source code, and disable emultation of setuid scripts when the 'nosuid' mount option is set. But, then every interpreter should do this [...] every suid-emulating interpreter. (For those who don't know, suidperl is a setuid root binary that securely *emulates* setuid scripts on operating systems that don't support them directly.) And yes, in theory, other suid-emulating interpreters ought to do the same checks -- but AFAIK, there _are_ no others. Why hasn't linus patched the kernel so that suid scripts are secure? It's an easy task, surely? Beats the heck out of me, Batman. As it is, noexec is almost useless. I can't help thinking that *all* interpreters *should* check noexec status. What's the point? Such files can be copied to /tmp and run there -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] When do you work? Whenever I'm not busy.
Re: suid-perl
According to Jules Bean: On Sun, 31 Jan 1999, Chip Salzenberg wrote: Every OS has a different set of mount options that may or may not be relevant to setuid security. I don't see what 'higher level' would be useful. The correct solution to this, surely, is for the mount nosuid to actually strip the suid bits of any files. So that any calls to stat() on a floppy simply won't see suid bits. I can see it both ways. Consider that I may wish to mount a filesystem nosuid for the purpose of making a tape backup. Would I want the suid bits turned off in the backup image? I think not. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] When do you work? Whenever I'm not busy.
Re: suid-perl
On Sun, 31 Jan 1999, Chip Salzenberg wrote: According to Jules Bean: On Sun, 31 Jan 1999, Chip Salzenberg wrote: Every OS has a different set of mount options that may or may not be relevant to setuid security. I don't see what 'higher level' would be useful. The correct solution to this, surely, is for the mount nosuid to actually strip the suid bits of any files. So that any calls to stat() on a floppy simply won't see suid bits. I can see it both ways. Consider that I may wish to mount a filesystem nosuid for the purpose of making a tape backup. Would I want the suid bits turned off in the backup image? I think not. Why not just mount it somewhere only you can get at it? Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: suid-perl
According to Jules Bean: On Sun, 31 Jan 1999, Chip Salzenberg wrote: Consider that I may wish to mount a filesystem nosuid for the purpose of making a tape backup. Would I want the suid bits turned off in the backup image? I think not. Why not just mount it somewhere only you can get at it? Touche'. I concede. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] When do you work? Whenever I'm not busy.
