On 2013-08-15 03:00:01, mallen wrote:
> On Tue Aug 13 23:54:35 2013, KENTNL wrote:
> > 1. The security risk is not obvious
>
> There are tons of security risks running perl setuid which are
> detailed pretty well in perlsec http://perldoc.perl.org/perlsec.html.
>
I think my question is more "What security risks exist specific are there that are specific to perldoc".
If you're arguing there's security risks in general from running perl as root, or running perl setuid, sure, I can't argue that, ... but if we wanted to "solve" that, perl itself would have to tell every user who ran it for *any* reason, "No, you may not run Perl as root, its too insecure" =)
Now if you're arguing about /setuid/ perl, ie: a perl that runs as root when called by a user as a result of filesystem bits that cause it to escalate privelage, thats a security risk, but thats a security risk for *every* perl program that is installed setuid.
In our problem scenario, the code is not being installed/run as *setuid*, it is merely running normally as root.
However, if a root user wants to do "perl -E"system(q[rm -rf /])", thats their problem. We dont' bar them from running perl simply because they're root =).
> > In addition, perldoc responds to many different command names (as a
> historical curiosity partly)
>
> See https://github.com/mrallen1/Pod-
> Perldoc/blob/master/lib/Pod/Perldoc.pm#L323-L386
>
> and it uses untainting pervasively throughout the codebase.
>
This, in itself, is not a security hole. No more than bash can cause gross damage if root invokes commands that do gross damage. The security hole is when root is tricked into doing insecure things they didn't intend on.
> > 2. Would be nice to have a way to go "Ok, I don't care about the
> > security, I'm a grown up" at the very least.
>
> I guess it would be possible to add a patch to *not* drop the setuid
> bits, but I don't think its going to
> solve the problem with parrot. IMO, the pattern would be
>
> # perldoc -d /tmp/foo.txt foo.pod
>
> and then later,
>
> # mv /tmp/foo.txt /final/place/in/my/path
>
> totally external to perldoc.
>
Thats the problem here though, it *is* doing perldoc -d ./target ./source and it *is* later moving the files to the final place.
However, ./ is controlled, and owned, and readable and writeable only by the user who created it: Root.
So when perldoc drops root, even though its install target is not the "OS", dropping privs means it can't write to any directory at all, because it can *ONLY* write to directories that are writeable by UID=nobody
And that *is* a potential security hole that is being introduced, because it means you have to make the directory writeable either by a) UID=nobody and UID=nobody *only* in *advance*, or you have to make the directory +RW to everyone. And both those scenarios create a directory, which a well timed attack could conceivably add their own files to that tree, which might be accidentally installed to the final system.
Just to clarify, I'm not so much nessecarily asking you to fix this /for/ parrot. That ship has sailed and parrot will have to find a workaround, though it would be nice if there was just a flag that controlled whether or not to drop privs, or a flag that specified what priv to drop to. ( And additionally, here, the problem with parrot is a problem with their tool-chaining, because "make install" should not be building documentation, it should just be installing it ).
Just when I encountered this bug(or misfeature), it was confusing as hell, because the vast majority of commandline tools don't drop privs, and debugging the cause of the read/write failure was rather challenging, because you're not expecting something like
gzcat foo -o bar # to die with a permissions problem when you are root, unless the filesystem is broken =)
