In the first post: Collaborative Work Simple and Exposed, I walked through Moss and Roy’s current working configuration. I demonstrated the risk they face by Jen, the Destroyer of work, who could delete all their work or read files that should be protected.

In this post, I’ll walk through the steps needed to convert their working directory into a much safer setup using groups. This work will require some unix admin stesp and I will summarize those.

Here are the Use-cases that I introduced in the first post and I will referr to most of these throughout this post:

  • Share edit files: As a team of developers, we want to edit the same file (usually a configuration file).

  • Adding group perms: As a team of developers, we want to add new files and not have to always remember to change the group for each file.

  • Disallow intruders: As a team of developers, we do not want someone that is not part of the team to have write or delete permission to our working directory.

  • Modifying old files to add group: As a team of developers that have started out using ugo+rwx on all our files, we want to switch over to using a group and reduce our permissions down just the group (o-rwx)

  • Run a script as group: As a team of developers, we want anyone on the team to run a script and anyone else on the team is permitted to kill and restart the script

Setup

To start with, I have re-set the working directory /mnt/reynholm at the point where Moss was working alone and Roy was added into the project.

[root /]$ su moss
[moss /]$ touch /mnt/reynholm/tinternet.txt
[moss /]$ ls -al /mnt/reynholm
total 8
drwxrwxrwx 2 moss moss 4096 Dec 31 19:56 .
drwxr-xr-x 3 root root 4096 Dec 31 19:38 ..
-rw-rw-r-- 1 moss moss    0 Dec 31 19:56 tinternet.txt
[moss /]$ exit
exit

Create a Group

When Roy started working on the project, they should ask the unix admin to create a group. Moss and Roy will need to bow their head to the Unix admin for several things.. this is the first.

[root /]$ groupadd stealth

[root /]$ tail -n 4 /etc/group
moss:x:1000:
roy:x:1001:
jen:x:1002:
stealth:x:1003:

Now we see that there is a group stealth that has been created. Another Unix admin request is needed to add both Roy and Moss to the stealth group.

[root /]$ usermod -a -G stealth moss
[root /]$ usermod -a -G stealth roy
[root /]$ id moss
uid=1000(moss) gid=1000(moss) groups=1000(moss),1003(stealth)
[root /]$ id roy
uid=1001(roy) gid=1001(roy) groups=1001(roy),1003(stealth)

Both Moss and Roy are now associated with the stealth group.

chgrp the working directory

The directory /mnt/reynholm was initially created by the Unix admin and given to Moss. Now that there is a group available, Moss or Roy will request that the Unix admin assign the stealth group to be the group owner of the /mnt/reynholm directory.

[root /]$ ls -ald /mnt/reynholm
drwxrwxrwx 2 moss moss 4096 Dec 31 19:56 /mnt/reynholm

[root /]$ chgrp stealth /mnt/reynholm

[root /]$ ls -ald /mnt/reynholm
drwxrwxrwx 2 moss stealth 4096 Dec 31 19:56 /mnt/reynholm

With the stealth group set as the group owner of the directory, anyone within the group can read, write or execute in the /mnt/reynholm directory.

chmod to restrict others

They will also ask the Unix admin to remove o=rwx permissions from the directory.1

Changing ownership on the root of their working directory can be done by the owner of the directory – in this case that is Moss. Moss can issue the command:

[moss /]$ chmod o-rwx /mnt/reynholm

[moss /]$ ls -ald /mnt/reynholm 
drwxrws--- 3 moss stealth 4096 Dec 31 21:02 /mnt/reynholm

[moss /]$ getfacl -pt /mnt/reynholm 
# file: /mnt/reynholm
USER   moss      rwx     
GROUP  stealth   rwx     
other            ---     

Removing other read, write and execute will remove the opportunity from someone outside the group to read or modify anything within the /mnt/reynholm directory.

Each person check umask

Another precaution is for each member of the group to review their umask setting. This setting is defined in the /etc/bashrc but can be re-set to within the $HOME/.bashrc. He umask setting defines the default permissions that will be applied to any new file that is created by the user.

For example, Roy’s umask setting is:

[root /]$ su roy
[roy /]$ umask
0002
[roy /]$ exit
exit

For Moss and Roy, the should completely lock out others from reading any newly created files, therefore thier individual umask should be set to 0007.

This can be done by adding the following line to the $HOME/.bashrc

umask 0007

For Moss and Roy, this is done by appending it to their $HOME/.bashrc

su roy
echo "umask 007" >> $HOME/.bashrc
exit

su moss
echo "umask 007" >> $HOME/.bashrc
exit

After adding this to the .bashrc, the next time either of them logs in, the umask will be defined.

setgid bit

Now both Roy and Moss can create files in the /mnt/reynholm directory and they can edit existing files that they have created. However they still can’t edit files that the other has created.

For example, consider the case where both Moss and Roy create a file.

[root /]$ su roy
[roy /]$ touch /mnt/reynholm/royfile.txt
[roy /]$ exit
exit

[root /]$ su moss
[moss /]$ touch /mnt/reynholm/mossfile.txt
[moss /]$ exit
exit

[root /]$ ls -al /mnt/reynholm
total 8
drwxrwx--- 2 moss stealth 4096 Dec 31 20:59 .
drwxr-xr-x 3 root root    4096 Dec 31 19:38 ..
-rw-rw---- 1 moss moss       0 Dec 31 20:59 mossfile.txt
-rw-rw---- 1 roy  roy        0 Dec 31 20:59 royfile.txt
-rw-rw-r-- 1 moss moss       0 Dec 31 19:56 tinternet.txt

Moss cannot write to a file created by Roy:

[root /]$ su moss

[moss /]$ echo "TESTING FROM MOSS" >> /mnt/reynholm/royfile.txt
bash: /mnt/reynholm/royfile.txt: Permission denied

[moss /]$ exit
exit

And Roy cannot write to a file created by Moss:

[root /]$ su roy

[roy /]$ echo "TESTING FROM ROY" >> /mnt/reynholm/mossfile.txt
bash: /mnt/reynholm/mossfile.txt: Permission denied

[roy /]$ exit
exit

Both Moss and Roy could fix this up manually using chgrp to change the group owner over to the stealth group.

[root /]$ su roy
[roy /]$ chgrp stealth /mnt/reynholm/royfile.txt 

[roy /]$ ls -al /mnt/reynholm
total 8   
drwxrwx--- 2 moss stealth 4096 Dec 31 20:59 .
drwxr-xr-x 3 root root    4096 Dec 31 19:38 ..
-rw-rw---- 1 moss moss       0 Dec 31 20:59 mossfile.txt
-rw-rw---- 1 roy  stealth    0 Dec 31 20:59 royfile.txt
-rw-rw-r-- 1 moss moss       0 Dec 31 19:56 tinternet.txt

[roy /]$ getfacl -pt /mnt/reynholm/royfile.txt
# file: /mnt/reynholm/royfile.txt
USER   roy       rw-
GROUP  stealth   rw-
other            ---

[roy /]$ exit
exit

Once Roy has chowned the royfile.txt to be group owned by stealth, then Moss is able to write information into the file.

[root /]$ su moss
[moss /]$ echo "TESTING FROM MOSS" >> /mnt/reynholm/royfile.txt
[moss /]$ exit
exit 

This could be painful if they had to do it each time a new file was added to the directory. Both Moss and Roy could get around this by running a command to periodically change the permissions of any files:

find /mnt/reynholm/ -gid `id -g` -exec chgrp stealth {} \;

This find command will search all files and directories within the /mnt/reynholm directory where the group owner is the same as the person running the command. For each file or directory that meets this critera, find will execute the chgrp command to change the group ownership over to stealth.

Fortunately there is another permissions change to fix this up in a more sustainable way and doesn’t require Moss and Roy to take proactive action.

The final Unix admin action needed is to set the setgid bit on the /mnt/reyholm directory. This is done with the following command:

[root /]$ chmod g+s /mnt/reynholm

[root /]$ ls -ald /mnt/reynholm
drwxrws--- 2 moss stealth 4096 Dec 31 20:59 /mnt/reynholm

[root /]$ getfacl -p /mnt/reynholm
# file: /mnt/reynholm
# owner: moss
# group: stealth
# flags: -s-
user::rwx
group::rwx
other::---

After the setgid bit is set on the directory, any files or directories that are created within the /mnt/reynholm directory will automatically be created with the group owner of the containing directory.

Here is an example with Moss driving:

[root /]$ su moss

[moss /]$ rm /mnt/reynholm/mossfile.txt
[moss /]$ touch /mnt/reynholm/mossfile.txt

[moss /]$ ls -al /mnt/reynholm/
total 12
drwxrws--- 2 moss stealth 4096 Dec 31 21:02 .
drwxr-xr-x 3 root root    4096 Dec 31 19:38 ..
-rw-rw---- 1 moss stealth    0 Dec 31 21:02 mossfile.txt
-rw-rw---- 1 roy  stealth   18 Dec 31 20:59 royfile.txt
-rw-rw-r-- 1 moss moss       0 Dec 31 19:56 tinternet.txt
[moss /]$ exit
exit

In this example you can see that the /mnt/reynholm/mossfile.txt file has been re-created and it automatically receives the group owner of the containing directory.

This is true with directories created as well:

[root /]$ su moss
[moss /]$ mkdir /mnt/reynholm/moss-subdir
[moss /]$ ls -al /mnt/reynholm
total 16
drwxrws--- 3 moss stealth 4096 Dec 31 21:02 .
drwxr-xr-x 3 root root    4096 Dec 31 19:38 ..
drwxrws--- 2 moss stealth 4096 Dec 31 21:02 moss-subdir
-rw-rw---- 1 moss stealth    0 Dec 31 21:02 mossfile.txt
-rw-rw---- 1 roy  stealth   18 Dec 31 20:59 royfile.txt
-rw-rw-r-- 1 moss moss       0 Dec 31 19:56 tinternet.txt
[moss /]$ exit
exit

Using the setgid bit enables all members of the team to create files within the group folder and share them, edit them, and delete them because of the group permission.

Summary of admin steps

Because I spread the steps out a little, here is a summary of the unix admin steps needed to configure users and a directory for group work.

  • Create the group

    • groupadd stealth
  • Associate the users with the group

    • usermod -a -G stealth moss
  • Change the group owner on the directory

    • chgrp stealth /mnt/reynholm
  • Set the setguid bit on the directory

    • chmod g+s /mnt/reynholm

And a reminder to the members of the group to review their umask setting and restrict it as necessary in their $HOME/.bashrc.

Cleaning up

Ok, so now that Moss and Roy have a group, are members of the group and have the setguid bit set on their shared working directory, they still have a few files that are individually owned that should all be set to have the stealth group owner. This cleanup will have to be executed by each that has non-group files or directories. Fortunately the command made easier by the find command.

[root /]$ su moss
[moss /]$ find /mnt/reynholm -gid `id -g` -ls
   197    0 -rw-rw-r--   1 moss     moss            0 Dec 31 19:56 /mnt/reynholm/tinternet.txt

[moss /]$ find /mnt/reynholm/ -gid `id -g` -exec chgrp stealth {} \;

[moss /]$ ls -al /mnt/reynholm/
total 16
drwxrws--- 3 moss stealth 4096 Dec 31 21:02 .
drwxr-xr-x 3 root root    4096 Dec 31 19:38 ..
drwxrws--- 2 moss stealth 4096 Dec 31 21:02 moss-subdir
-rw-rw---- 1 moss stealth    0 Dec 31 21:02 mossfile.txt
-rw-rw---- 1 roy  stealth   18 Dec 31 20:59 royfile.txt
-rw-rw-r-- 1 moss stealth    0 Dec 31 19:56 tinternet.txt

[moss /]$ exit
exit

Jen the destroyer of work returns

Jen is back and she wants to tidy up again. What happens when she tries to clean up the /mnt/reynholm directory?

[root /]$ su jen
[jen /]$ ls /mnt/reynholm
ls: cannot open directory /mnt/reynholm: Permission denied
[jen /]$ rm -rf /mnt/reynholm/*
rm: cannot remove '/mnt/reynholm/*': Permission denied
[jen /]$ exit
exit

That’s right! She can’t! Since she is not included in the stealth group and the directory world write and execute bits have been removed, she is no longer able to clean up or even see what’s in the /mnt/reynholm directory.

Use Cases Followup

To refresh, here are the use-cases that I introduced at the beginning of the series.

  • Share edit files
    • I think this one has been demonstrated between Moss and Roy.
  • Adding group perms
    • Yep this one was just covered with setguid example.
  • Disallow intruders
    • We have shown that someone not in the group can be restricted
  • Modifying old files to add group
    • Covered that in the Cleanup section
  • Run a script as a group
    • Uh Oh!
    • Well, I haven’t been able to demonstrate this one. Unfortunately this is more difficult than it looks. When I started this, I thought it was going to involve setgid bit, however it does not due to security risks. Controlling Shared Processes will be the subject of the last in this three part series:

Mulitpart post

Because this work started to get too long for my attention span, I have broken it up into three parts:

Reference


  1. Correction 2019/01/03. Realized that user that owns the directory can set permission bits on the directory. ↩︎