Default group

Wed Oct 17 19:52:30 UTC 2012

First:  that's why we need an interface that handles POSIX ACLs
properly, long-overdue.

Second, this is not simple.  This is a recommendation to use shotgun
approach to everything and leave gaping holes because it's convenient.
 I don't mean to say this is a critical 100% immediate security hole;
I mean that trying to carefully, craftily use the current scheme is
very complex.

Let's first assume we have three users:

jkirk
ksingh
wriker

Now, let's say any of these wants to give any of the others access to
his files in general (i.e. his $HOME).  Let's for our example say
jkirk wants wriker to have access.

First, he must find the sysadmin.  The sysadmin must then put wriker
in group jkirk.  Also, ~jkirk must be group-readable, as must any
files.

To do this without a sysadmin, the user must be sysadmin.  Either none
or one of these users can do it all; or all of them can and then we're
not dealing with any kind of document security.

With POSIX ACL instead AND AN INTERFACE FOR IT, jkirk simply
right-clicks on his Home directory in Nautilus (Konqueror Thunar etc),
hits Permissions, Add, puts in 'wriker' with 'read, access files
inside directory'.  Since his files are all read-write by group
(umask=002) instead of just readable (umask=022), this makes all his
files writable by wriker, of course.  That's not the point here,
HOWEVER it is a concern.

Notice this is simple, and the user can do it themselves.

Someone raised shared directories and SGID.  When we get to SGID we've
stepped slightly outside simple, but I'll allow it.

Let's say now jkirk wants to share specific files with wriker, and
specific other files with ksingh.  Let's tackle ksingh first.

jkirk could put a directory in a shared location, with SGID,
accessible by jkirk, and have the sysadmin give ksingh the jkirk
group.  This would, of course, also allow ksingh into anything else
accessible by jkirk's group--so if his home directory is open, or if
he has a file shared with wriker by putting wriker in the jkirk group,
those files are also accessible by ksingh as a matter of course.

Repeat:  those OTHER files are also accessible by ksingh as a matter of course.

Instead, ksingh could have jkirk put in the ksingh group; this creates
the same problem for ksingh.

Next of course jkirk tries to create a shared directory to share some
files with wriker, but of course that makes things complex.  Maybe
wriker does it, but then he shares with ksingh, which means wriker has
the same problem of jkirk getting files he wants to only share with
ksingh, or jkirk must accept the problem of sharing files with ksingh
when he only wants those files to go to wriker (and with wriker when
he wants those files only to go to ksingh).

Then, everybody gives up and just uses e-mail to send files back and forth.

Instead, jkirk creates a directory to share with ksingh.  The
directory is mode 700, owned by jkirk, and in the group 'users', and
with the SGID bit set (so not mode 700, more mode 02700?  I forget
what's SUID, SGID, and sticky, ok?).  He right clicks on it, hits
Properties, Permissions, adds ksingh with rwx (remember X on
directories is "access files inside").  When jkirk or ksingh creates
files inside, they are read/write by group and automatically in the
group 'users', so jkirk and ksingh can access all files in the
directory.

Then, jkirk creates a directory to share with wriker.  He does the
same, except adds wriker to the access list.  Same thing, but ksingh
can't access any of the files in it because the directory is 700 and
so he can't list the files and, even if he could, he can't actually
traverse the directory to access the files.  Similarly, wriker can't
access the directory shared by ksingh.

And, of course, jkirk has been granted no additional permissions.
Still, wriker or ksingh could do the same to give jkirk or each other
shared directories to access.  It's a simple create directory, right
click, add access, and there's no implications of other access by
other people because of other stuff you did with other directories at
other times.  Also, the system administrator isn't involved.

That's called "keeping it simple."  What's simple with the current
design is nobody has to develop a user interface for managing POSIX
ACLs--which would of course involve work, and open source developers
are a limited resource because they only work on things they actually
care about.

What's simple about the proposed design is the end user doesn't have
to change what group people are in or do complicated association
graphs and jump through hoops to get the simplest sharing between two
users to not open up other files they don't intend to share.

Also important is, with the current design, if you share with more
than one or two other users or you have overlapping access you WILL
wind up giving excessive access to someone.  For example, one user
creates a shared directory with two users, and another shared
directory with only one of those two users.  You can't do it.  You'd
share both directories with both users.  The second user would have to
share a directory to you--direction is suddenly critically important
to semantics of overall access.  And of course when you have three
users doing this to each other, suddenly there's no arrangement that
works.

In truth it's the same problem as just ... basic Unix groups.  You
want Developers and Managers to all be able to access a certain
folder, but you don't want to make all Developers also Managers
because they'd be able to do things like monkey with their own salary.
 Then you decide you don't want to make Managers Developers because
they'll monkey with the code even though they're not supposed to and
most of them were good programmers 10 years ago but have gotten rusty
and refuse to admit it.  What now?  Only difference is our use case
has more unstructured sharing, which means the problems that creep up
creep up REALLY FAST and much more often and usually go unnoticed.

On Wed, Oct 17, 2012 at 3:14 PM, Nicolas Michel
<be.nicolas.michel at gmail.com> wrote:
> John,
>
> Do you know KISS?
> So ACL works well. But it's really more complicated to use than UGO and
> surely to understand who has which access to what. Trust me it can be really
> hard to get it with complex configurations.
>
> So I would say : why use a complex solution for a simple need?
>
> Regards,
> Nicolas
>
>
> 2012/10/17 John Moser <john.r.moser at gmail.com>
>>
>> On Wed, Oct 17, 2012 at 10:44 AM, Marc Deslauriers
>> <marc.deslauriers at canonical.com> wrote:
>> > On 12-10-17 09:59 AM, John Moser wrote:
>> >> I suggest all users should go into group 'users' as the default group,
>> >> with $HOME default to 700 and in the group 'users'.  A umask of 027 or
>> >> the traditional 022 is still viable:  the files in $HOME are not
>> >> visible because you cannot list the contents of $HOME (not readable)
>> >> or change into it to access the files within (not executable).  A user
>> >> can grant permissions to other users to access his files simply by
>> >> making the directory readable by them--by 'users' or others (thus
>> >> everyone) or by fine-grained POSIX ACLs selecting for individual users
>> >> and groups.
>> >>
>> >
>> > We want users to be able to share files with other users. Having $HOME
>> > be 700 defeats that purpose. See:
>> >
>> >
>> > https://wiki.ubuntu.com/SecurityTeam/Policies#Permissive_Home_Directory_Access
>> >
>>
>> Which, as I said, is accomplished by adding the user or an appropriate
>> group to the Extended ACL of $HOME, as the umask is still permissive
>> and the files are all owned by a common user group.  It can also be
>> blanket accomplished by adding read access to group or others on
>> $HOME, which would return the system to effectively as it is now.
>>
>> > Also, one of the reasons for using User Private Groups, is to be able to
>> > create directories that are used by multiple users, by setting the
>> > setgid on the directory. With a default umask of 022, users need to
>> > manually set group permissions each time they create a file.
>> >
>>
>> Setting setgid on the directory to allow multiple users to add files
>> to it still requires that the users be in the group or that the
>> directory be world-writable. The proper way to accomplish this is,
>> again, to place the directory into the shared 'users' group and grant
>> individual user or group access via ACLs, rather than a shotgun
>> approach by which either the directory is either world-writable or the
>> users have to be put into some other user's group and then suddenly
>> have blanket access to that user's files unless he tightens down
>> permissions on his $HOME.
>>
>> setgid would also do ... just about nothing, since without setUID on
>> the directory the file's permissions are still g-w.  Although some
>> Googling is telling me that Ubuntu changed the default umask to 002
>> back in Oneric, so apparently yeah this works, caveat above paragraph.
>>
>> In short, the current method is a lot of "this works..." with a lot of
>> unintended consequences.
>>
>>
>> > Marc.
>> >
>> >
>> > --
>> > Marc Deslauriers
>> > Ubuntu Security Engineer     | http://www.ubuntu.com/
>> > Canonical Ltd.               | http://www.canonical.com/
>> >
>> > --
>> > Ubuntu-devel-discuss mailing list
>> > Ubuntu-devel-discuss at lists.ubuntu.com
>> > Modify settings or unsubscribe at:
>> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>>
>> --
>> Ubuntu-devel-discuss mailing list
>> Ubuntu-devel-discuss at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
>
>
>
> --
> Nicolas MICHEL