Steve Langasek | 1 Oct 02:06 2006
Picon

Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

On Sat, Sep 30, 2006 at 11:56:30PM +0100, Thiemo Seufer wrote:
> > > I meant the the earlier security bug you mentioned. To me, the solution
> > > for the earlier bug as well as the current one looks like keeping the
> > > font cache in /var but maintaining it via a mktexmf user.

> > The problem is that mktexmf is a shell script (=no suid possible) that
> > is started with the rights of the user. So the former solution required
> > all users that wanted to use TeX to have write access below
> > /var/cache/fonts.

> Then I fail to understand

>   a) why the old solution was a security problem when it does something
>      similiar to e.g. /var/mail, and leaves the root-reserved part of
>      the filesystem free,

>   b) why moving the cache to $HOME or /tmp fixed the problem, given
>      that all three probably reside on the same partition.

The old solution was a security problem because the directories were
world-writable -- /var/mail is not, the directory is only writable by the
'mail' group -- which almost certainly makes symlink attacks possible,
looking at the source of mktexmf, as well as cache poisoning attacks.

The new solution is only better if the cache is written in the home
directory; if it's written to /tmp/texfonts for any reason, the security is
just as bad.

--

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
(Continue reading)

Steve Langasek | 1 Oct 02:10 2006
Picon

Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

On Sat, Sep 30, 2006 at 08:19:22PM +0200, Ralf Stubner wrote:
> On Sat, Sep 30, 2006 at 18:12 +0100, Thiemo Seufer wrote:
> > Frank Küster wrote:
> > > Thiemo Seufer <ths <at> networkno.de> wrote:

> > > > So, if I understand that correctly, the bug was fixed by running mktexmf
> > > > as non-root, and the change of the cache location is only a collateral.

> > > No, or I do not understand what you mean.

> > I meant the the earlier security bug you mentioned. To me, the solution
> > for the earlier bug as well as the current one looks like keeping the
> > font cache in /var but maintaining it via a mktexmf user.

> The problem is that mktexmf is a shell script (=no suid possible)

Where does the input for the cache come from?  If the input is always from a
privileged location (i.e., /usr/share, /usr/lib, /etc), then it's possible
-- and, I think, vastly preferable -- to have an suid wrapper for mktexmf to
manage /var/cache.

If the font input comes from user-specified, non-privileged locations, then
this can't ever be safely written to a shared location.

--

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon <at> debian.org                                   http://www.debian.org/

(Continue reading)

Florent Rougon | 1 Oct 13:23 2006
Picon

Bug#390349: per-user font caching in /tmp

Frank Küster <frank <at> kuesterei.ch> wrote:

> There's a third, in 05Texmf.cnf:
>
> -VARTEXFONTS = /tmp/texfonts
> +VARTEXFONTS = /tmp/$USER/texfonts
>
> The only thing I do not know is whether $USER is always guaranteed to be
> set... 

Anyway, it's predictable, so I think it has more or less the same
problems as /tmp/texfonts...

--

-- 
Florent

Frank Küster | 1 Oct 14:46 2006
Picon

Bug#390349: [Thiemo Seufer] Re: Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

Picon
From: Thiemo Seufer <ths <at> networkno.de>
Subject: Re: Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging
Date: 2006-09-30 22:56:30 GMT
Ralf Stubner wrote:
> On Sat, Sep 30, 2006 at 18:12 +0100, Thiemo Seufer wrote:
> > Frank Küster wrote:
> > > Thiemo Seufer <ths <at> networkno.de> wrote:
> > > >
> > > > So, if I understand that correctly, the bug was fixed by running mktexmf
> > > > as non-root, and the change of the cache location is only a collateral.
> > > 
> > > No, or I do not understand what you mean.
> > 
> > I meant the the earlier security bug you mentioned. To me, the solution
> > for the earlier bug as well as the current one looks like keeping the
> > font cache in /var but maintaining it via a mktexmf user.
> 
> The problem is that mktexmf is a shell script (=no suid possible) that
> is started with the rights of the user. So the former solution required
> all users that wanted to use TeX to have write access below
> /var/cache/fonts.

Then I fail to understand

  a) why the old solution was a security problem when it does something
     similiar to e.g. /var/mail, and leaves the root-reserved part of
     the filesystem free,

  b) why moving the cache to $HOME or /tmp fixed the problem, given
     that all three probably reside on the same partition.

Thiemo


--

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding  <at>  Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Frank Küster | 1 Oct 14:46 2006
Picon

Bug#390349: Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

Steve Langasek <vorlon <at> debian.org> wrote:

> The old solution was a security problem because the directories were
> world-writable -- /var/mail is not, the directory is only writable by the
> 'mail' group -- which almost certainly makes symlink attacks possible,
> looking at the source of mktexmf, as well as cache poisoning attacks.
>
> The new solution is only better if the cache is written in the home
> directory; if it's written to /tmp/texfonts for any reason, the security is
> just as bad.

It might be a bit better, since filling up /var is less severe than
filling up /tmp (unless both are on the same filesystem...).  The
symlink attacks are in fact completely hypothetical, since the things
you can do in a Metafont, TeX pk of TeX font metric file are very
limited, and the format ist strict.

What we have done is to alleviate this potential problem for most
systems and users.  For users without a writable home directory, it's
nearly as bad as it has always been (and still is in sarge).  But since
no one has ever regarded that as a relevant security problem, I don't
see why it should now be one.

Regards, Frank
--

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding  <at>  Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Frank Küster | 1 Oct 14:46 2006
Picon

Bug#390349: [Steve Langasek] Re: Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

Picon
From: Steve Langasek <vorlon <at> debian.org>
Subject: Re: Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging
Date: 2006-10-01 00:06:54 GMT
On Sat, Sep 30, 2006 at 11:56:30PM +0100, Thiemo Seufer wrote:
> > > I meant the the earlier security bug you mentioned. To me, the solution
> > > for the earlier bug as well as the current one looks like keeping the
> > > font cache in /var but maintaining it via a mktexmf user.

> > The problem is that mktexmf is a shell script (=no suid possible) that
> > is started with the rights of the user. So the former solution required
> > all users that wanted to use TeX to have write access below
> > /var/cache/fonts.

> Then I fail to understand

>   a) why the old solution was a security problem when it does something
>      similiar to e.g. /var/mail, and leaves the root-reserved part of
>      the filesystem free,

>   b) why moving the cache to $HOME or /tmp fixed the problem, given
>      that all three probably reside on the same partition.

The old solution was a security problem because the directories were
world-writable -- /var/mail is not, the directory is only writable by the
'mail' group -- which almost certainly makes symlink attacks possible,
looking at the source of mktexmf, as well as cache poisoning attacks.

The new solution is only better if the cache is written in the home
directory; if it's written to /tmp/texfonts for any reason, the security is
just as bad.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon <at> debian.org                                   http://www.debian.org/


--

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding  <at>  Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Frank Küster | 1 Oct 14:48 2006
Picon

Bug#390349: Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

[please note the different bug number]

Steve Langasek <vorlon <at> debian.org> wrote:

> Where does the input for the cache come from?  If the input is always from a
> privileged location (i.e., /usr/share, /usr/lib, /etc), then it's possible
> -- and, I think, vastly preferable -- to have an suid wrapper for mktexmf to
> manage /var/cache.
>
> If the font input comes from user-specified, non-privileged locations, then
> this can't ever be safely written to a shared location.

The input can come from the current directory, the user's own TEXMF tree
or any directory specified in the MFINPUTS (etc.) variable.

Regards, Frank
--

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding  <at>  Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Frank Küster | 1 Oct 14:53 2006
Picon

Bug#390349: per-user font caching in /tmp

Florent Rougon <f.rougon <at> free.fr> wrote:

> Frank Küster <frank <at> kuesterei.ch> wrote:
>
>> There's a third, in 05Texmf.cnf:
>>
>> -VARTEXFONTS = /tmp/texfonts
>> +VARTEXFONTS = /tmp/$USER/texfonts
>>
>> The only thing I do not know is whether $USER is always guaranteed to be
>> set... 
>
> Anyway, it's predictable, so I think it has more or less the same
> problems as /tmp/texfonts...

You are right.  I was fooled because Thiemo somewhere said that a common
cache would "break" mktexmf, in the sense as it broke in the FTBFS bug
that originally caused this discussion.  If that would be a problem,
per-user directories would help, but since it isn't a problem, we do not
need this "solution" to it.

In fact IMO there is no problem at all, at least not one that is
important enough to care about now.

Regards, Frank
--

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding  <at>  Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Florent Rougon | 1 Oct 17:21 2006
Picon

Bug#356853: Scalable LaTeX font: Licensing question regarding ae fonts

Dear Lars,

"Lars Engebretsen" <lars <at> engebretsen.se> wrote:

> Basically, I don't really have the energy to care about intricacies of
> licenses, but if you feel that a) you want to do the work and provide
> me with a file that I can then upload to CTAN, and b) that this does
> not change the licensing in such a way that the package can no longer
> be in teTeX and friends, I'm fine with doing the necessary updates.

Your conditions look very reasonable to me. I discussed this with Frank
Küster, and we agreed that using the LPPL (the LaTeX Project Public
License) is probably the most natural choice for the ae package.

I had a look at all source files in order to provide you with a
ready-to-upload tarball (or zip file, whichever is more convenient to
you), but there are a few complications: several files weren't written
by you originally, or have been modified by other people. We need these
people (i.e., the copyright holders of the files) to tell us that they
agree distributing these files under the LPPL.

More precisely, I think it would be wise to use the wording suggested in
the LPPL, i.e. :

  % This work may be distributed and/or modified under the
  % conditions of the LaTeX Project Public License, either version 1.3
  % of this license or (at your option) any later version.

You can read the whole LPPL text here:

  http://www.latex-project.org/lppl/lppl-1-3c.html

I'll now paste the various contributors I identified, along with the
files they (appear to) hold copyright on:

,----
| Alan Jeffrey
| 
|   src/aelatin.mtx
|   src/aelatint.mtx
|   src/aet1.etx
|   src/ot1tt.etx
| 
| 
| Matthias Koeppe
| 
|   src/aelatin.mtx
| 
| 
| Sebastian Rahtz
| 
|   src/aet1.etx
| 
| 
| Denis Roegel
| 
|   tex/aecompl.sty
| 
| 
| Rolf Niepraschk
| 
|   tex/ae.sty
| 
| 
| Gilbert Ritschard
| 
|   tex/ae.sty
`----

Do you want me to contact these people, or do you prefer taking care of
that yourself?

In the latter case, I can provide you with their email addresses, as I
have collected them as part of my little investigation.

Many thanks for your cooperation.

Regards,

--

-- 
Florent
Florent Rougon | 1 Oct 18:42 2006
Picon

Bug#356853: Scalable LaTeX font: Licensing question regarding ae fonts

[ Resending the message to a different address, as the previous one
  bounced:

<lars <at> engebretsen.se>: host resolver3.levonline.com[217.70.32.98] said: 554
    <lars <at> engebretsen.se>: Recipient address rejected: no such user (in reply
    to RCPT TO command) ]

Dear Lars,

"Lars Engebretsen" <lars <at> engebretsen.se> wrote:

> Basically, I don't really have the energy to care about intricacies of
> licenses, but if you feel that a) you want to do the work and provide
> me with a file that I can then upload to CTAN, and b) that this does
> not change the licensing in such a way that the package can no longer
> be in teTeX and friends, I'm fine with doing the necessary updates.

Your conditions look very reasonable to me. I discussed this with Frank
Küster, and we agreed that using the LPPL (the LaTeX Project Public
License) is probably the most natural choice for the ae package.

I had a look at all source files in order to provide you with a
ready-to-upload tarball (or zip file, whichever is more convenient to
you), but there are a few complications: several files weren't written
by you originally, or have been modified by other people. We need these
people (i.e., the copyright holders of the files) to tell us that they
agree distributing these files under the LPPL.

More precisely, I think it would be wise to use the wording suggested in
the LPPL, i.e. :

  % This work may be distributed and/or modified under the
  % conditions of the LaTeX Project Public License, either version 1.3
  % of this license or (at your option) any later version.

You can read the whole LPPL text here:

  http://www.latex-project.org/lppl/lppl-1-3c.html

I'll now paste the various contributors I identified, along with the
files they (appear to) hold copyright on:

,----
| Alan Jeffrey
| 
|   src/aelatin.mtx
|   src/aelatint.mtx
|   src/aet1.etx
|   src/ot1tt.etx
| 
| 
| Matthias Koeppe
| 
|   src/aelatin.mtx
| 
| 
| Sebastian Rahtz
| 
|   src/aet1.etx
| 
| 
| Denis Roegel
| 
|   tex/aecompl.sty
| 
| 
| Rolf Niepraschk
| 
|   tex/ae.sty
| 
| 
| Gilbert Ritschard
| 
|   tex/ae.sty
`----

Do you want me to contact these people, or do you prefer taking care of
that yourself?

In the latter case, I can provide you with their email addresses, as I
have collected them as part of my little investigation.

Many thanks for your cooperation.

Regards,

--

-- 
Florent

Gmane