cvs commit: src/etc rc.subr
Yar Tikhiy
FreeBSD src repository
Modified files:
etc rc.subr
Log:
Allow for /usr/bin/env when parsing the shebang line from an
interpreted $command. Some "portable" sofware packages use such a
line to skip the task of figuring out the absolute pathname of the
interpreter at install time, e.g.:
#!/usr/bin/env python
It is insecure, but a popular book on Python seems to have advised
it to a wide audience. Hence a number of such scripts in the ports,
mostly written in Python.
PR: bin/100287
MFC after: 1 week
Revision Changes Path
1.73 +5 -0 src/etc/rc.subr
_______________________________________________
cvs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-u...@freebsd.org"
Mike Pritchard
> yar 2006-12-31 11:07:29 UTC
>
> FreeBSD src repository
>
> Modified files:
> etc rc.subr
> Log:
> Allow for /usr/bin/env when parsing the shebang line from an
> interpreted $command. Some "portable" sofware packages use such a
> line to skip the task of figuring out the absolute pathname of the
> interpreter at install time, e.g.:
>
> #!/usr/bin/env python
>
> It is insecure, but a popular book on Python seems to have advised
> it to a wide audience. Hence a number of such scripts in the ports,
> mostly written in Python.
If its insecure, than why allow it? If the ports need a patch to make it
secure, then they should be patched.
I don't like seeing something from rc.subr with a comment about it
being less secure....
(sorry if this message is a duplicate... been messing with my postfix
settings, and it looked like the first one never made it out)
--
Mike Pritchard
m...@FreeBSD.org or m...@mppsystems.com
"If tyranny and oppression come to this land, it will be in the guise
of fighting a foreign enemy." - James Madison (1787)
Mike Pritchard
> yar 2006-12-31 11:07:29 UTC
>
> FreeBSD src repository
>
> Modified files:
> etc rc.subr
> Log:
> Allow for /usr/bin/env when parsing the shebang line from an
> interpreted $command. Some "portable" sofware packages use such a
> line to skip the task of figuring out the absolute pathname of the
> interpreter at install time, e.g.:
>
> #!/usr/bin/env python
>
> It is insecure, but a popular book on Python seems to have advised
> it to a wide audience. Hence a number of such scripts in the ports,
> mostly written in Python.
If its insecure, than why allow it? If the ports need a patch to make it
secure, then they should be patched.
I don't like seeing something from rc.subr with a comment about it
being less secure....
Brooks Davis
--2fHTh5uZTiUOsy+g
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Dec 31, 2006 at 11:04:11AM -0600, Mike Pritchard wrote:
> On Sun, Dec 31, 2006 at 11:07:29AM +0000, Yar Tikhiy wrote:
> > yar 2006-12-31 11:07:29 UTC
> >=20
> > FreeBSD src repository
> >=20
> > Modified files:
> > etc rc.subr=20
> > Log:
> > Allow for /usr/bin/env when parsing the shebang line from an
> > interpreted $command. Some "portable" sofware packages use such a
> > line to skip the task of figuring out the absolute pathname of the
> > interpreter at install time, e.g.:
> > =20
> > #!/usr/bin/env python
> > =20
> > It is insecure, but a popular book on Python seems to have advised
> > it to a wide audience. Hence a number of such scripts in the ports,
> > mostly written in Python.
>=20
> If its insecure, than why allow it? If the ports need a patch to make it
> secure, then they should be patched. =20
>=20
> I don't like seeing something from rc.subr with a comment about it
> being less secure....
It's only a security problem in the case of an insecure path. This
isn't generally the case for rc.d's execution context. It's only
a security issue of administrators are stupid enough to place
untrustworthy directories such as "." in root's path.
-- Brooks
--2fHTh5uZTiUOsy+g
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFFmsfUXY6L6fI4GtQRAm1oAJwOPp9NWYxRE0dyqdPbpTA/H8Y0iACfUqqs
M2CkWo0uZDfrbN95/f4m/r8=
=cbPy
-----END PGP SIGNATURE-----
--2fHTh5uZTiUOsy+g--
Yar Tikhiy
> On Sun, Dec 31, 2006 at 11:07:29AM +0000, Yar Tikhiy wrote:
> > yar 2006-12-31 11:07:29 UTC
> >
> >
> > Modified files:
> > etc rc.subr
> > Allow for /usr/bin/env when parsing the shebang line from an
> > interpreted $command. Some "portable" sofware packages use such a
> > line to skip the task of figuring out the absolute pathname of the
> > interpreter at install time, e.g.:
> >
> >
> > It is insecure, but a popular book on Python seems to have advised
> > it to a wide audience. Hence a number of such scripts in the ports,
> > mostly written in Python.
>
> secure, then they should be patched.
>
> being less secure....
Then feel free to patch src/sys/kern/imgact_shell.c for it is the
root of the evil, and face a torrent of complaints. OTOH rc.subr's
_find_processes() deals with a different side of the issue that has
no security implications because the insecure script is supposed
to be already running. My commit message just explained why we
have to pay attention to the case at all in rc.subr. It was my
fault that I didn't realise some folks would be totally caught by
the flypaper word "security."
--
Yar
Garance A Drosehn
>On Sun, Dec 31, 2006 at 11:07:29AM +0000, Yar Tikhiy wrote:
>> yar 2006-12-31 11:07:29 UTC
>>
>> FreeBSD src repository
>>
>> Modified files:
>> etc rc.subr
>> Log:
>> Allow for /usr/bin/env when parsing the shebang line from an
>> interpreted $command. Some "portable" sofware packages use such a
>> line to skip the task of figuring out the absolute pathname of the
>> interpreter at install time, e.g.:
>>
>> #!/usr/bin/env python
>>
>> It is insecure, but a popular book on Python seems to have advised
>> it to a wide audience. Hence a number of such scripts in the ports,
>> mostly written in Python.
>
>make it secure, then they should be patched.
The commit-comment makes the change sound more scary than it really is.
And while I am a little surprised that nothing seems to set a value for
PATH in the /etc/rc.d/* scripts, I do see that:
/etc/rc:PATH=/sbin:/bin:/usr/sbin:/usr/bin
/etc/rc:export HOME PATH
/etc/rc.shutdown:PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin
/etc/rc.shutdown:export HOME PATH
So, running some script via /usr/bin/env is not an issue during the
normal startup and shutdown operations. I guess it theoretically
might be an issue when people run a /etc/rc.d/<whatever> file by hand,
as root, and only if they have already set a dangerous value for PATH.
I.e, that administrator *already* has a security issue, and using
/usr/bin/env merely means the startup line in some /etc/rc.d/* scripts
are not protected from that already-existing security problem.
However, this change doesn't actually run anything with /usr/bin/env.
It only makes rc.subr work reliably for those scripts which have
decided to use /usr/bin/env.
On the flip side, the /usr/bin/env trick is explicitly recommended
for the perl and ruby communities, in addition to python. The
practice is described in multiple books for those languages. It is
by far the easiest way to write a portable script. In this case,
"portable" also covers scripts which are only running a variety of
FreeBSD configurations. It isn't just a matter of portability
between FreeBSD vs Linux vs Solaris. It could get quite tricky to
write a script which is certain to get the right version of python
on every installation of FreeBSD. (This is more of an issue for
python and ruby than perl. Perl used to be part of the base system,
so we have the special /usr/bin/perl link even when perl is installed
from ports. We do not create a special link like that for ruby or
python).
Yar's comment may have made this change sound scary, but in practice
the security exposure for this specific change is zero. I understand
what Yar was thinking of when he mentioned it the way he did, but the
change itself does not cause any security problem. None. Zero.
--
Garance Alistair Drosehn = dro...@rpi.edu
Senior Systems Programmer or g...@FreeBSD.org
Rensselaer Polytechnic Institute; Troy, NY; USA