Re: Bug#37606: /var/spool/texmf/ls-R unwritable
> The main reason I didn't want to have mktex{mf,tfm,pk} be setuid is
> because they run all sorts of different programs - metafont, gsftopk,
> etc. - which can (IIRC) be replaced by the user. Even if they can't,
> their inputs can, and the inputs are turing-complete macro languages.
> If mktex{mf,tfm,pk} drop privileges before invoking the real generator
> programs, I'll be happy.
I don't think it would work to drop privileges before starting up the
generator programs -- that would defeat the point. But what must be
done is: clear the environment, reset PATH to something known and
secure and setuid(geteuid()). The combined effect of the first and
third of these would also result in the texmf search paths being
unaffected by anything that the user might do, which is crucially
important. Resetting PATH prevents the user from getting their own
programs into the works. And the fact that this will run as a
dedicated user (tex) means that if there were any security holes, the
worst that could be done is to interfere with the generated fonts,
which would be hardly worse than the present situation. And
hopefully, the result will be secure, and then we are a lot better
off.
> I would also rather not install suidperl if it can be avoided.
I had realised that from other people's postings on another issue.
It's something I'm thinking about, but my ideas on how to write these
scripts as setuid scripts (even with a wrapper) are still in pre-alpha
stage. Part of the difficulty is that the Web2C system allows the
binaries to be installed anywhere. I have to ensure that the PATH
contains the correct directory if both (1) the script is running
setuid and (2) the directory of the script is not /usr(/local)/bin.
I'm thinking about it
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer. [EMAIL PROTECTED]
-*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Bug#37606: /var/spool/texmf/ls-R unwritable
On Sun, 16 May 1999 21:31:14 +0100 (BST), Julian Gilbey wrote:
>> >> >And having mktex{mf,tfm,pk}
>> >> >writing to a scratch directory defeats the purpose of making the fonts
>> >> >directory read only, as anyone could then create a corrupt font file
>> >> >in the scratch directory and run mktexupd.
>> >>
>> >> This is a problem, but isn't there some simple, efficient way to
>> >> validate font files?
>> >
>> >Yes: recreate them and compare the outputs. You don't want to just
>> >check that the files are valid, but also that they have the correct
>> >content.
>>
>> Ok, I give up, we do have to do it your way.
>
>Yes, it's something I struggled with a few years ago in our department
>where corrupt fonts had been created: there was no simple way to
>determine this fact without recreating them. (You could compare the
>embedded checksums with those in the corresponding tfm, but how do you
>know that is correct if the tfm is also autogenerated?)
The main reason I didn't want to have mktex{mf,tfm,pk} be setuid is
because they run all sorts of different programs - metafont, gsftopk,
etc. - which can (IIRC) be replaced by the user. Even if they can't,
their inputs can, and the inputs are turing-complete macro languages.
If mktex{mf,tfm,pk} drop privileges before invoking the real generator
programs, I'll be happy.
I would also rather not install suidperl if it can be avoided.
zw
Re: Bug#37606: /var/spool/texmf/ls-R unwritable
> >> >And having mktex{mf,tfm,pk}
> >> >writing to a scratch directory defeats the purpose of making the fonts
> >> >directory read only, as anyone could then create a corrupt font file
> >> >in the scratch directory and run mktexupd.
> >>
> >> This is a problem, but isn't there some simple, efficient way to
> >> validate font files?
> >
> >Yes: recreate them and compare the outputs. You don't want to just
> >check that the files are valid, but also that they have the correct
> >content.
>
> Ok, I give up, we do have to do it your way.
Yes, it's something I struggled with a few years ago in our department
where corrupt fonts had been created: there was no simple way to
determine this fact without recreating them. (You could compare the
embedded checksums with those in the corresponding tfm, but how do you
know that is correct if the tfm is also autogenerated?)
Still tough, though.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer. [EMAIL PROTECTED]
-*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Bug#37606: /var/spool/texmf/ls-R unwritable
On Fri, 14 May 1999 19:04:01 +0100 (BST), Julian Gilbey wrote:
>> On Thu, 13 May 1999 15:02:40 +0100 (BST), Julian Gilbey wrote:
>> >> Glad to hear all of this. I just have one comment:
>> >>
>> >> > - The mktexlsr, mktexdir and mktexupd scripts must not be setuid.
>> >> >If they are, anyone could run them, which is unnecessary. Any
>> >> >extra privileges they require will be gained when they are called
>> >> >from other setuid processes.
>> >>
>> >> It seems to me that *only* these three should be setuid, since only
>> >> these three need elevated privileges. mktextfm, etc. should be
>> >> changed to write the output into a scratch directory, and have
>> >> mktexupd move it into place.
>> >>
>> >> Yes, this does mean anyone can invoke them, but if properly designed
>> >> no damage can be done, and this restricts the scope of the changes and
>> >> the scope of the specially privileged code much better.
>> >
>> >No, absolutely not. If mktexupd is setuid, then anyone can make it do
>> >anything to the ls-R file, I would guess.
>>
>> Only if mktexupd is misdesigned; it ought to be capable of validating
>> updates.
>
>How?
The proper location for a file to be installed in /var/spool/texmf is
uniquely determined by its name, right? You hand it a file, and it
puts it where it belongs. No other changes to ls-R are possible via
(this version of) mktexupd
Moot, though, given what you say below.
>> >And having mktex{mf,tfm,pk}
>> >writing to a scratch directory defeats the purpose of making the fonts
>> >directory read only, as anyone could then create a corrupt font file
>> >in the scratch directory and run mktexupd.
>>
>> This is a problem, but isn't there some simple, efficient way to
>> validate font files?
>
>Yes: recreate them and compare the outputs. You don't want to just
>check that the files are valid, but also that they have the correct
>content.
Ok, I give up, we do have to do it your way.
zw
Re: Bug#37606: /var/spool/texmf/ls-R unwritable
> On Thu, 13 May 1999 15:02:40 +0100 (BST), Julian Gilbey wrote:
> >> Glad to hear all of this. I just have one comment:
> >>
> >> > - The mktexlsr, mktexdir and mktexupd scripts must not be setuid.
> >> >If they are, anyone could run them, which is unnecessary. Any
> >> >extra privileges they require will be gained when they are called
> >> >from other setuid processes.
> >>
> >> It seems to me that *only* these three should be setuid, since only
> >> these three need elevated privileges. mktextfm, etc. should be
> >> changed to write the output into a scratch directory, and have
> >> mktexupd move it into place.
> >>
> >> Yes, this does mean anyone can invoke them, but if properly designed
> >> no damage can be done, and this restricts the scope of the changes and
> >> the scope of the specially privileged code much better.
> >
> >No, absolutely not. If mktexupd is setuid, then anyone can make it do
> >anything to the ls-R file, I would guess.
>
> Only if mktexupd is misdesigned; it ought to be capable of validating
> updates.
How?
> >And having mktex{mf,tfm,pk}
> >writing to a scratch directory defeats the purpose of making the fonts
> >directory read only, as anyone could then create a corrupt font file
> >in the scratch directory and run mktexupd.
>
> This is a problem, but isn't there some simple, efficient way to
> validate font files?
Yes: recreate them and compare the outputs. You don't want to just
check that the files are valid, but also that they have the correct
content.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer. [EMAIL PROTECTED]
-*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Bug#37606: /var/spool/texmf/ls-R unwritable
On Thu, 13 May 1999 15:02:40 +0100 (BST), Julian Gilbey wrote:
>> Glad to hear all of this. I just have one comment:
>>
>> > - The mktexlsr, mktexdir and mktexupd scripts must not be setuid.
>> >If they are, anyone could run them, which is unnecessary. Any
>> >extra privileges they require will be gained when they are called
>> >from other setuid processes.
>>
>> It seems to me that *only* these three should be setuid, since only
>> these three need elevated privileges. mktextfm, etc. should be
>> changed to write the output into a scratch directory, and have
>> mktexupd move it into place.
>>
>> Yes, this does mean anyone can invoke them, but if properly designed
>> no damage can be done, and this restricts the scope of the changes and
>> the scope of the specially privileged code much better.
>
>No, absolutely not. If mktexupd is setuid, then anyone can make it do
>anything to the ls-R file, I would guess.
Only if mktexupd is misdesigned; it ought to be capable of validating
updates.
>And having mktex{mf,tfm,pk}
>writing to a scratch directory defeats the purpose of making the fonts
>directory read only, as anyone could then create a corrupt font file
>in the scratch directory and run mktexupd.
This is a problem, but isn't there some simple, efficient way to
validate font files?
zw
Re: Bug#37606: /var/spool/texmf/ls-R unwritable
> Glad to hear all of this. I just have one comment:
>
> > - The mktexlsr, mktexdir and mktexupd scripts must not be setuid.
> >If they are, anyone could run them, which is unnecessary. Any
> >extra privileges they require will be gained when they are called
> >from other setuid processes.
>
> It seems to me that *only* these three should be setuid, since only
> these three need elevated privileges. mktextfm, etc. should be
> changed to write the output into a scratch directory, and have
> mktexupd move it into place.
>
> Yes, this does mean anyone can invoke them, but if properly designed
> no damage can be done, and this restricts the scope of the changes and
> the scope of the specially privileged code much better.
No, absolutely not. If mktexupd is setuid, then anyone can make it do
anything to the ls-R file, I would guess. And having mktex{mf,tfm,pk}
writing to a scratch directory defeats the purpose of making the fonts
directory read only, as anyone could then create a corrupt font file
in the scratch directory and run mktexupd. The mktexupd program is
essentially only used in two situations: (1) when called from
mktex{mf,tfm,pk} and (2) when called from texconfig or a postinst. In
the latter situations, it will be running as root if it is doing
anything useful, and all that must be done in that case is to ensure
that the ownership of the ls-R files is unchanged. This is not too
difficult to arrange if you are running as root!
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer. [EMAIL PROTECTED]
-*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Bug#37606: /var/spool/texmf/ls-R unwritable
On Thu, 13 May 1999 11:25:10 +0100 (BST), Julian Gilbey wrote: >[Cc'ing to -devel] > >> Package: tetex-base >> Version: 0.9.990406-1 >> >> Out of the box, /var/spool/texmf/ls-R is owned by root and mode 644. >> Therefore all font generation operations get an error: >> >> /usr/share/texmf/web2c/mktexupd: /var/spool/texmf/ls-R unwritable. >> >> Changing it to mode 666 works around the problem, but the right thing >> would be to make mktexupd setgid to some group (daemon?) and make >> /var/spool/texmf/ls-R writable by that group. Possibly the same thing >> should be done to the subdirectories of /var/spool/texmf, mode 1777 >> can be problematic. > >You are correct. A fully working solution which closes the security >holes is not straightforward, though. I am currently working on a >project to solve this problem. In the meantime though, note that the >font _is_ generated and stored, will be found by kpathsea on the next >occasion that it is needed, and will be written into the ls-R file the >next time the tetex cron job runs. Glad to hear all of this. I just have one comment: > - The mktexlsr, mktexdir and mktexupd scripts must not be setuid. >If they are, anyone could run them, which is unnecessary. Any >extra privileges they require will be gained when they are called >from other setuid processes. It seems to me that *only* these three should be setuid, since only these three need elevated privileges. mktextfm, etc. should be changed to write the output into a scratch directory, and have mktexupd move it into place. Yes, this does mean anyone can invoke them, but if properly designed no damage can be done, and this restricts the scope of the changes and the scope of the specially privileged code much better. zw
Re: Bug#37606: /var/spool/texmf/ls-R unwritable
[Cc'ing to -devel]
> Package: tetex-base
> Version: 0.9.990406-1
>
> Out of the box, /var/spool/texmf/ls-R is owned by root and mode 644.
> Therefore all font generation operations get an error:
>
> /usr/share/texmf/web2c/mktexupd: /var/spool/texmf/ls-R unwritable.
>
> Changing it to mode 666 works around the problem, but the right thing
> would be to make mktexupd setgid to some group (daemon?) and make
> /var/spool/texmf/ls-R writable by that group. Possibly the same thing
> should be done to the subdirectories of /var/spool/texmf, mode 1777
> can be problematic.
You are correct. A fully working solution which closes the security
holes is not straightforward, though. I am currently working on a
project to solve this problem. In the meantime though, note that the
font _is_ generated and stored, will be found by kpathsea on the next
occasion that it is needed, and will be written into the ls-R file the
next time the tetex cron job runs.
My current state of progress is:
- Working Perl Kpathsea interface and Kpathsea module (although they
are labelled as alpha, there are some minor bugs apparently and
the Makefiles need cleaning up). You can download it from
http://www.debian.org/~jdg.
- I have rewritten all of the mktex scripts in Perl except for
mktex{mf,tfm,pk}. (You might say, "Huh? But that's all of them!"
But this means that I have dealt with mktex.opt, mktexnam,
mktexnam.opt, mktexdir, mktexdir.opt, mktexupd and mktexlsr. Just
the three last ones to go.) Unfortunately, these are currently on
paper only; you can have a photocopy of them if you really desire ;)
Still to go:
- At present, I am working on making the Perl scripts behave
identically (modulo bugs) to the shell script counterparts. When
this is working, I fully intend to introduce variant behaviour if
the script is running setuid. We need the scripts to be setuid
tex if they are to be secure, as otherwise, the owner of the
process will still own any font files created, which is Not Good.
Then the writeable font trees would be owned by tex, mode 755, and
ls-R would be owned by tex with mode 644.
- The mktexlsr, mktexdir and mktexupd scripts must not be setuid.
If they are, anyone could run them, which is unnecessary. Any
extra privileges they require will be gained when they are called
from other setuid processes. The mktex{mf,tfm,pk} scripts should
do the following if they are running setuid (and do the same as
present if not):
. In a child process, drop any privileges and check the
locations of the files which would need to be created (by
calling mktexnam). Report back to the parent process.
. In the parent process, compare the results against the value of
SYSTEXMF obtained from the system texmf.cnf files, having
cleared (but saved) any environment variables. If the location
which would be used is not within the SYSTEXMF trees, then drop
privileges, reinstate the old environment and create the font.
Since the process is now running as the user with no
privileges, any nasty settings in their personal texmf.cnf or
environment will be ignored.
. Otherwise, we continue with privileges and a sanitised
environment to figure out where *we* would like to place the
created fonts by calling mktexnam again. If it is not in one
of the recognised places (SYSTEXMF, VARFONTS), give up.
Otherwise, go ahead and create the font.
- Issues which need to be addressed for this to work:
. mktexnam currently makes assumptions about the location of a
font based on the writeability of a directory. We must ensure
that these assumptions are correct in this scheme.
. We must be very careful to fork a child process to do the font
creation *before* invoking any of the Kpathsea routines, as the
texmf.cnf files cannot be reinitialised easily. A better
solution may well be to have mktex{mf,tfm,pk} be setuid C
wrappers which call the non-setuid mktex{mf,tfm,pk}.pl scripts;
then they can simply exec another copy of themselves and load
the Kpathsea library afresh. (This also avoids people needing
to have suidperl around if they don't want it.) Doing this
properly is probably a bit painful (will probably use parts of
Kpathsea's proginit.c to get the right location of the mktex
scripts).
. This sound like a lot of computational work, and that it will
be a lot slower than the present system, but since the ls-R
databases will need loading only a handful of times, this
should turn out to be much faster.
Comments appreciated!
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer. [EMAIL PROTECT
