Re: Re: Re: Re: CVE request(?): gpg: improper file permssions set when en/de-crypting files

[Tavis Ormandy <taviso () cmpxchg8b com>]

Michael Gilbert <mgilbert () debian org> wrote:

> On Mon, Sep 24, 2012 at 3:06 PM, Tavis Ormandy wrote:
> > What complexity?
>
> The complexity of fixing permission handling in just about every single
> unix application.

It's already a requirement, it's not complex. 

> > > First of all, gpg is not the only application that would need to be
> > > "privacy-aware". Every single application that produces new files from
> > > existing ones to propagate permissions from those original files to
> > > the new ones, which would be pretty much everything.
> >
> > I'm not sure what you're talking about, when you invoke open() with
> > O_CREAT, you need to put the correct value in the third parameter. I
> > don't know what that has to do with propogation.
>
> If gpg is supposed to propagate permissions based on its input file
> permissions to output files, then the broad implications are that whole
> class of applications that derive new files need to do that as well.

I don't know what "propagate" means, it's supposed to put the permissions it
wants in the parameters to open, yes. I think you're re-inventing capability
systems, and are convinced that's what I want (I don't).

> The point is retaining appropriate permissions across a chain of commands,
> rather than resorting to the umask, which you are arguing is the wrong
> thing to do for sensitive data.

I would not argue any such thing, such capability systems are the domain of
academics ;-).

What I am saying is that if you want to create a file with 0644, you put
0644 in the arguments to open, not set it to 0666 and say "fix your umask".

> > I think you've misunderstood the problem, and it's trivial to solve.
>
> No, I'm thinking about the broader implication.  If you're arguing that
> gpg should be modified to better handle permissions, then all applications
> potentially handling sensitive information should as well: file editors,
> and what not.  Otherwise, what makes gpg such a special case?

I think you've confused my post with someone elses.

Tavis.

-- 
-------------------------------------
taviso () cmpxchg8b com | pgp encrypted mail preferred
-------------------------------------------------------