Derek Martin wrote in
<[email protected]>:
|On Fri, Aug 07, 2020 at 12:56:34AM +0200, Vincent Lefevre wrote:
|> On 2020-08-06 10:50:23 -0500, Derek Martin wrote:
|>> On Wed, Jul 29, 2020 at 12:55:07PM -0500, Derek Martin wrote:
|>>> On Tue, Jul 28, 2020 at 08:03:23PM +0200, [email protected] wrote:
|>>>> The thread, and even older threads referenced there, is from 2007.
|>>>> Since then, the security field have evolved - now we have SeLinux,
|>>>> Apparmor and other techniques which are capable to provide even
|>>>> better security than umask(077)
|>>>
|>>> None of those changes affect this issue in any meaningful way.
|>>> SELinux predates that thread by at least two years (longer, though it
|>>> was not generally available to the public until ~2005). The arguments
|>>> made in those threads still stand, and I will not repeat them here.
|>>
|>> And FWIW, here's a more precise and detailed description I posted MUCH
|>> more recently than 2007, which explains why this is a bad idea.
|>> Everything here remains true, regardless of any evolution you think
|>> has happened in the security world.
|>>
|>> https://www.mail-archive.com/[email protected]/msg49810.html
...
|Are you serious, Vincent? I'm pretty sure you well know that this is
|a horrible idea, clearly contrary to best security practices, that no
...
|> On such a system using umask (007) for secondary ids seems logical
|> and safe.
|
|No, it doesn't. Even if someone were to run Mutt on such a horribly
|mismanaged system, its system security is generally suspect, so it is
|even more important for Mutt to make sure the files are never saved
|readable by anyone other than the user who created them. Regardless,
|Mutt should stick to its guns concerning maintaining the security of
|its users' files.
|
|And remember, what we're trading here is the, what, 3 seconds it takes
|for the user to type "chmod 644 *" (or similar) if they really want to
|do this. It's a small price to pay for the best insurance available
|that no one is ever able to read your sensitive mail attachments
|without you explicitly taking action to allow them to. You'll never
|be able to blame Mutt for this.
I take that bait. As an outsider i nonetheless think this is very
much of an over- reaction. Users have an umask, and they usually
have it for a reason. Unless they do not, and inherit the 022
that is very often set in global default /etc/profile's. There
you have a culprit.
#?0|kent:sec.arena$ umask
027
So for me my MUA instance integrates in my usual environment, and
thus i want it to embed itself the way i want. And want 027.
That is, in fact i want
if [ ${UID} -eq 0 ]; then
umask 0022
elif [ -n "${FACL_OK}" ]; then
umask 0027
elif [ -f ./.umask ]; then
umask "`cat ./.umask`" || umask 0027
else
echo >&2 '.profile: no FACL_OK, no ~/.umask: umask 0077'
umask 0077
fi
Therefore i have cheerfully implemented *umask* functionality once
a(n actually non-) user asked for it, for the MUA i maintain. It
applies to files which are explicitly saved. It does not apply to
temporary data, never. I do not really see a security threat,
since by default it will be set to 0077, until the user explicitly
changes it. What is wrong with that?
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
