Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   UPG and the default umask (http://www.linux-archive.org/debian-development/369071-upg-default-umask.html)

Drake Wilson 05-10-2010 05:24 PM

UPG and the default umask
 
Quoth Aaron Toponce <aaron.toponce@gmail.com>, on 2010-05-10 10:40:58 -0600:
> On 5/10/2010 10:23 AM, Julien Cristau wrote:
> > On Mon, May 10, 2010 at 10:14:00 -0600, Aaron Toponce wrote:
> > Are there reasons for making the switch? With user groups, umask 002 or
> > 022 doesn't make a difference. To switch off user groups, you set
> > USERGROUPS=no in adduser.conf, and that's it.
>
> The biggest reason for making the change is when group collaboration
> becomes a necessity.

FWIW (which is probably vanishingly little), I find that dealing with
significant group or even inter-user interactions on Unix machines
eventually gets nearly impossible in the absence of full POSIX ACL
support. Modern Debian supports this well with a suitable filesystem
on the backend, though depending on your interop requirements there
may be other problems.

In this case, the umask problem you mention:

> Suppose you have an 'devel' group on the system,
> and a central directory where the collaboration happens. Because of the
> default umask value being '0022', the users must make sure that they
> have 'umask 0002' in their shell rc file, or as appropriate, [...]

goes away almost entirely if you [setfacl -m d:g::rwx] (or d:g::rx,
whichever is appropriate) the central directory. (This still doesn't
catch mv'd files, but neither does umask, and that's sort of another
kettle of fish.)

I regularly set my personal umask to 0077 because I find accidentally
creating files that other users can snoop on to be more dangerous than
having to chmod files after the fact. Conversely, setting default
ACLs is one of the first things I do when setting up collaboration
directories.

---> Drake Wilson


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100510172420.GA30750@drache.begriffli.ch">http://lists.debian.org/20100510172420.GA30750@drache.begriffli.ch

Aaron Toponce 05-10-2010 06:07 PM

UPG and the default umask
 
On 5/10/2010 11:24 AM, Drake Wilson wrote:
> FWIW (which is probably vanishingly little), I find that dealing with
> significant group or even inter-user interactions on Unix machines
> eventually gets nearly impossible in the absence of full POSIX ACL
> support. Modern Debian supports this well with a suitable filesystem
> on the backend, though depending on your interop requirements there
> may be other problems.

I have no problems with FACLs, except they add to added complexity and
administration to the filesystem. They're difficult to maintain when
multiple groups and users are involved. When scattered about the
filesystem, it's not trivial to remove ACL permissions when users or
groups are removed from the system. Making the default umask '0002'
system-wide on a base install, however, is extremely trivial. Having the
administrator then set FACLs as appropriate can be at their discretion
without getting in the way.

> I regularly set my personal umask to 0077 because I find accidentally
> creating files that other users can snoop on to be more dangerous than
> having to chmod files after the fact. Conversely, setting default
> ACLs is one of the first things I do when setting up collaboration
> directories.

FACLs on collaborative project directories and files is almost a
necessity, and I understand the security of changing your umask to
something more tight on multi-user systems. And if the umask switches
the other direction to '0077' in the name of security, I don't see any
problems there. However, leaving it at '0022' is just historical
baggage, and there's no good reason to leave it there.

--
. O . O . O . . O O . . . O .
. . O . O O O . O . O O . . O
O O O . O . . O O O O . O O O

Klaus Ethgen 05-10-2010 07:07 PM

UPG and the default umask
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am Mo den 10. Mai 2010 um 17:14 schrieb Aaron Toponce:
> $ umask 0002
> $ touch anotherfile
> $ ls -l anotherfile
> -rw-rw-r-- 1 foo foo 0 May 10 10:06 anotherfile
>
> As it sits, having the default umask set as '0022' isn't breaking
> anything, but it's no longer needed. It's just historical baggage coming
> from the 'users' group on older UNIX systems, where any new user added
> to the system was added to the 'users' group by default. Thus, removing
> the write bit made sense. It doesn't make any sense with UPG.

I still makes sense. The user will not win with the lazier umask but he
will probably loose security.

See the case the user wants another person in his own group to share
files. Then he might set the files readable for his group only but not
for world. So the other user can read this data. But he cannot write it
as it might be intended.

Setting the umask to 002 let the other user _edit_ all files the user
did create in the past with that umask factual giving away most of his
files.

The better Idea would be to set the user mask to 027 which then add a
new value of security.

If a user want the group to have write permissions this should be set
explicit. By the way, with zsh you can make directory profiles which
set the umask depending on the directory.

> For comparison's sake, Fedora (and as a result, RHEL/CentOS/etc) have
> implemented '0002' as their default umask, as they implement UPG.

Yes. And that is one big security issue!

> I guess I'm more or less curious why we're still using this outdated
> umask value with UPG. What would it take for Debian to update our
> default umask to match the UPG scheme? Is this doable for Sqeeze? Are
> there reasons for not making the switch?

Hopefully not!

Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.de/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEVAwUBS+hZg5+OKpjRpO3lAQrqxQf/Y0tHKXEiHnQePMxs/DItSecDn/aw+gsN
qcTsKw4qU6Wk95KsV5LLsRTT7uFN9/RtOtz+KUa0YaWIyLVKGMxjRbQYFceaG490
gY5QlK1AVrqHDdFipLUK12mgb63s9VDMxFqXFHpUPa5GFbMQ6R GcrN3KbxIVNeG7
khcHhOqOiATC7E0GN4jg+eSGqmD/szSlLqKBaJJVfbPbG2T91NvZqxG+cXLwuhpW
cYQqpxVA9jYLFhEBq4Fe5JhEFOUfcV+zxT8BJ0TVVsvuzvN7M5 PJV7Pb9XaBXeCz
HsHU+7+Yojt2r03KeFwacjg65xZvVqQPEFNWBnnJCcd9qMdsI3 iIuw==
=qeHa
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100510190747.GC19222@ikki.ethgen.de">http://lists.debian.org/20100510190747.GC19222@ikki.ethgen.de

Aaron Toponce 05-10-2010 07:35 PM

UPG and the default umask
 
On 5/10/2010 1:07 PM, Klaus Ethgen wrote:
> I still makes sense. The user will not win with the lazier umask but he
> will probably loose security.
>
> See the case the user wants another person in his own group to share
> files. Then he might set the files readable for his group only but not
> for world. So the other user can read this data. But he cannot write it
> as it might be intended.
>
> Setting the umask to 002 let the other user _edit_ all files the user
> did create in the past with that umask factual giving away most of his
> files.

The point of UPG is to not put users you don't trust in your private
group. That's why it's called "private". :) If you don't trust users in
your UPG, then the administrator should setup a different group, and put
the necessary users in that group.

> The better Idea would be to set the user mask to 027 which then add a
> new value of security.
>
> If a user want the group to have write permissions this should be set
> explicit. By the way, with zsh you can make directory profiles which
> set the umask depending on the directory.

I'm all for increasing security, but it always comes at a cost. Nothing
in security is free. In this case, the convenience of setting up group
collaboration directories becomes a pain to administer, as the group
write bit is never set, and cron jobs, profile-specific umask values, or
FACLs are used instead, adding to the complexity of the system.

--
. O . O . O . . O O . . . O .
. . O . O O O . O . O O . . O
O O O . O . . O O O O . O O O

Klaus Ethgen 05-10-2010 10:46 PM

UPG and the default umask
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

Am Mo den 10. Mai 2010 um 20:35 schrieb Aaron Toponce:
> > See the case the user wants another person in his own group to share
> > files. Then he might set the files readable for his group only but not
> > for world. So the other user can read this data. But he cannot write it
> > as it might be intended.
> >
> > Setting the umask to 002 let the other user _edit_ all files the user
> > did create in the past with that umask factual giving away most of his
> > files.
>
> The point of UPG is to not put users you don't trust in your private
> group. That's why it's called "private". :)

You can never trust anybody for giving him rights to _all_ of your
files. So this assuming is never true and a user will not have any
benefit of this group if the umask is 002!

> If you don't trust users in your UPG, then the administrator should
> setup a different group, and put the necessary users in that group.

Give me one case where this is true. If there is a group for sharing
purpose the users will use it -- and will lower there security down to
nothing. Setting a default umask of 002 is highly negligent!

> I'm all for increasing security, but it always comes at a cost.

Thats true. But setting the umask to 002 will lower them for no benefit.

> In this case, the convenience of setting up group collaboration
> directories becomes a pain to administer, as the group write bit is
> never set, and cron jobs, profile-specific umask values, or FACLs are
> used instead, adding to the complexity of the system.

Well, all cases I know about where collaboration was setted up, the
person who did was knowing exactly what he did. And that is the way it
should. Don't let users do something if they do not know what
consequences it will have -- specialize in security!

The crazy idea of setting the umask to 002 per default will end in many,
many systems where the users have a low as nothing security for they
important files only to serve some few use cases where the persons
normally know how to get rid of anyway.

Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.de/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEVAwUBS+iMqZ+OKpjRpO3lAQqG3gf+M2O3qx+FFXgOT9V7VH +nx2Hcs5u1w2k9
Bk7ALBwQhZJKJV7oioyDx7GCBXnp/R2cpyyIsq8/dtT8I2+sCIuR5K6r18DRgGkB
At8Z6u0HEl/8Pl/lwnBaBhgr18iD8oUN8WXvIiS/La4n562gQfqG2Bw008QycEoz
ywWQzlOGahdfA9RA+luY3t+w6fT0+R4kU3za/C5tF6TY1pNtyyywvMrsf6sQGjES
JevSyP3FRix7scvSxtg4F/+9RBX8ei8bKe4gg13f8Em1i3p7CXbko+GfFDq0s3bs
5IxMUxN1LIXjZMaLyYwfeGasFjJlyZAb0JDY47xy9oLzQJBw8/k9xQ==
=8V8t
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100510224601.GD19222@ikki.ethgen.de">http://lists.debian.org/20100510224601.GD19222@ikki.ethgen.de

Don Armstrong 05-11-2010 12:34 AM

UPG and the default umask
 
On Mon, 10 May 2010, Aaron Toponce wrote:
> If the default umask is '0002' on a UPG system,
> then this checklist item doesn't need to be worried about.

If you want to use usergroups by default, add something like:

session optional pam_umask.so usergroups

to /etc/pam.d/login


Don Armstrong

--
I'm wrong to criticize the valor of your brave men. It's important to
die for one's country when it means being the subject of a king who
wears a ruffled collar or a pleated one.
-- Cyrano de Bergerac

http://www.donarmstrong.com http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100511003432.GG8358@teltox.donarmstrong.com">htt p://lists.debian.org/20100511003432.GG8358@teltox.donarmstrong.com

Steve Langasek 05-11-2010 09:49 AM

UPG and the default umask
 
On Mon, May 10, 2010 at 05:34:32PM -0700, Don Armstrong wrote:
> On Mon, 10 May 2010, Aaron Toponce wrote:
> > If the default umask is '0002' on a UPG system,
> > then this checklist item doesn't need to be worried about.

> If you want to use usergroups by default, add something like:

> session optional pam_umask.so usergroups

> to /etc/pam.d/login

Which won't have any effect on any services except for console tty logins
(no effect on X logins, ssh, etc).

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

Don Armstrong 05-11-2010 03:59 PM

UPG and the default umask
 
On Tue, 11 May 2010, Steve Langasek wrote:
> On Mon, May 10, 2010 at 05:34:32PM -0700, Don Armstrong wrote:
> > On Mon, 10 May 2010, Aaron Toponce wrote:
> > > If the default umask is '0002' on a UPG system,
> > > then this checklist item doesn't need to be worried about.
>
> > If you want to use usergroups by default, add something like:
>
> > session optional pam_umask.so usergroups
>
> > to /etc/pam.d/login
>
> Which won't have any effect on any services except for console tty logins
> (no effect on X logins, ssh, etc).

If you want those services affected, you can edit their service files
directly. (Or, if you want everything that includes common-session
affected, you can shove it in there.)


Don Armstrong

--
I will not make any deals with you. I've resigned. I will not be
pushed, filed, stamped, indexed, briefed, debriefed or numbered. My
life is my own. I resign.
-- Patrick McGoohan as Number 6 in "The Prisoner"

http://www.donarmstrong.com http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100511155927.GM8358@teltox.donarmstrong.com">htt p://lists.debian.org/20100511155927.GM8358@teltox.donarmstrong.com

Aaron Toponce 05-11-2010 04:13 PM

UPG and the default umask
 
On 5/10/2010 4:46 PM, Klaus Ethgen wrote:
> You can never trust anybody for giving him rights to _all_ of your
> files. So this assuming is never true and a user will not have any
> benefit of this group if the umask is 002!

I trust my wife to all of my files.

>> If you don't trust users in your UPG, then the administrator should
>> setup a different group, and put the necessary users in that group.
>
> Give me one case where this is true. If there is a group for sharing
> purpose the users will use it -- and will lower there security down to
> nothing. Setting a default umask of 002 is highly negligent!

We have a 'weblogic' group where many user accounts are added, so they
cane manipulate webolgic domains and configurations. Would you like more
examples?

> Thats true. But setting the umask to 002 will lower them for no benefit.

I've told you how making the umask '0002' increases collaboration for
development teams. And it doesn't change the security of files that has
your UPG as the group of your files/dirs. Everyone not you, or a member
of your UPG still falls under the 'other' permissions, so for the sake
of security, you might as well change it to '0007'. My argument is about
the group permission, not other.

> The crazy idea of setting the umask to 002 per default will end in many,
> many systems where the users have a low as nothing security for they
> important files only to serve some few use cases where the persons
> normally know how to get rid of anyway.

Explain the security implications of '0002'. Your home directory will be
'drwxrwxr-x foo foo', so anyone who is not user 'foo' or in the UPG
'foo' won't be able to modify a thing. If you're concerned about them
viewing the files, then '0007' would give 'drwxrwx--- foo foo'. Setting
the write bit on the group doesn't change any security mechanism for the
user 'foo' or his UPG 'foo'.

If you're concerned about a developer in a collaboration group doing
something nasty, then they shouldn't be on the team. Otherwise, remove
them from the group, restore from backup, and carry on.

It's easy to say "in the name of security", without really thinking
about what you're advocating. Updating the umask value to allow the
write bit on groups when UPG is setup (as it is by default) just makes
sense. Keeping the write bit off the group, means we're too lazy to
change old historical baggage.

--
. O . O . O . . O O . . . O .
. . O . O O O . O . O O . . O
O O O . O . . O O O O . O O O

Klaus Ethgen 05-11-2010 04:54 PM

UPG and the default umask
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

Am Di den 11. Mai 2010 um 17:13 schrieb Aaron Toponce:
> > You can never trust anybody for giving him rights to _all_ of your
> > files. So this assuming is never true and a user will not have any
> > benefit of this group if the umask is 002!
>
> I trust my wife to all of my files.

Good. :-)

> >> If you don't trust users in your UPG, then the administrator should
> >> setup a different group, and put the necessary users in that group.
> >
> > Give me one case where this is true. If there is a group for sharing
> > purpose the users will use it -- and will lower there security down to
> > nothing. Setting a default umask of 002 is highly negligent!
>
> We have a 'weblogic' group where many user accounts are added, so they
> cane manipulate webolgic domains and configurations. Would you like more
> examples?

That was not the point. That you can use other groups for different
purposes might be clear. The point here is about the UPG itself. So
group foo for user foo. And this is the dangerous point.

> > Thats true. But setting the umask to 002 will lower them for no benefit.
>
> I've told you how making the umask '0002' increases collaboration for
> development teams.

If you need such collaboration stuff you are welcome to set it up on
your system. There is not that much more work in telling the users that
they have to change there umask when collaborating. However, you have to
do that step in any case as there are many users setting they own umask
in a startup script.

> And it doesn't change the security of files that has your UPG as the
> group of your files/dirs. Everyone not you, or a member of your UPG
> still falls under the 'other' permissions,

And that is exactly the point. The only advantage of a UPG is to give
other users a bit more rights than other. So you add them into your own
group. With umask of 022 that will do no harm. With umask of 027 that is
a real improvement. But with the umask of 002 that is very very
dangerous!

And adding this danger only to set a default for the special case of
collaboration stuff where you have to tell the users anyway to set there
umask, is a bit to much collateral damage!

> so for the sake of security, you might as well change it to '0007'.

That was not the point. And I show you how to use the UPG usefull with
setting the umask to 027.

> My argument is about the group permission, not other.

Right, mine too.

> > The crazy idea of setting the umask to 002 per default will end in many,
> > many systems where the users have a low as nothing security for they
> > important files only to serve some few use cases where the persons
> > normally know how to get rid of anyway.
>
> Explain the security implications of '0002'. Your home directory will be
> 'drwxrwxr-x foo foo', so anyone who is not user 'foo' or in the UPG
> 'foo' won't be able to modify a thing. If you're concerned about them
> viewing the files, then '0007' would give 'drwxrwx--- foo foo'. Setting
> the write bit on the group doesn't change any security mechanism for the
> user 'foo' or his UPG 'foo'.

As long as the user do not use his UPG at all. And in that case the UPGs
are useless at all.

Any use case involving the UPG would suffer from a umask of 002.

> If you're concerned about a developer in a collaboration group doing
> something nasty, then they shouldn't be on the team. Otherwise, remove
> them from the group, restore from backup, and carry on.

Collaboration groups are a very special use case of POSIX group design.
There is no UPG involved.

> It's easy to say "in the name of security", without really thinking
> about what you're advocating.

It is easy to break security when not thinking what collateral damage a
change will do. I think I made the point very clear above.

> Updating the umask value to allow the write bit on groups when UPG is
> setup (as it is by default) just makes sense.

In the most cases, no, no, no! Only in a very few use cases that might
make sense.

> Keeping the write bit off the group, means we're too lazy to change
> old historical baggage.

Aha.

Maybe the whole bunch of security is historical baggage we learned in
the past. Just throw it away as it is historical baggage.

Did you even think about other use cases than the very special one of
collaboration directories? (Sorry to tell this question but I am really
in doubt if you understand the point I talked about.)

Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.de/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEVAwUBS+mLsJ+OKpjRpO3lAQqJDwf/ShMklFffEpFO75hXgVnNtXqbPTuMhhft
I74bONZMhCP8ATZ/25SZAUWfif93cGtxNztwKU7KRBe5cPyHuSODBK4slyPXeNG9
9AC+8PLAWkp//LCxX4Oq0I/XcD3MlVdoiZl+0JRoEB8bxK8KFf6nt8IXz1GXzrCG
//b7jSZ2vfevrBvby5VVyBsnXDoYM74nXxmqUQok8ub+nBfGmWoU JzlxP9z+xCsp
q9VUkQKqft69OJ0bE92PPq595yAYzf3tlzt+bkQ7Mz4+0UixhT/84ZK2m6TQ4mn1
HuKiunQ1ywdbXxl/TXEMCSYB2J3E3pG24u421Iglb1MwPLggLrPB1w==
=QgJC
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100511165408.GE9959@ikki.ethgen.de">http://lists.debian.org/20100511165408.GE9959@ikki.ethgen.de


All times are GMT. The time now is 07:27 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.