[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 24 Sep 2012 23:46:06 +0200
From: Tavis Ormandy <taviso@...xchg8b.com>
To: oss-security@...ts.openwall.com
Subject: Re: Re: Re: Re: CVE request(?): gpg: improper file permssions set when en/de-crypting files
Michael Gilbert <mgilbert@...ian.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@...xchg8b.com | pgp encrypted mail preferred
-------------------------------------------------------
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
