We run Endless OS in corrections (jails) with students sharing a device using different logins. We were just told one student using the terminal was making copies of other students Documents folders so he could read them, they were keeping private journals on the device.
I went ahead and was successfully able to replicate this issue. Using terminal as user1:
cp /sysroot/home/user2/Documents/* ./
Dropped all of user2’s Documents into my own home folder, where I could read them without issue.
Is this the intended security settings? We don’t allow users to individually password protect docs, nor do I think they should have to in order to avoid this kind of thing.
I don’t mean to pile on here, but I’m just totally confounded by this one. As a regular user, I can navigate to Documents, click + Other Locations, then through the GUI navigate to the sysroot/home/admin and actually view unprotected pictures of the Device Admin!? This can’t be good.
I just checked and remembered that these are the default permissions for many systems not just Endless. Here is an explanation from a trusted user on StackExchange:
It should be noted that even if a user puts her or his files in a directory only s/he can read, someone who takes out the hard drive can mount it in another computer as an administrator to view and modify all the contents. File based encryption¹ keeps away some prying eyes², full disk encryption or at least an encrypted container ensures that no encrypted files can be modified or deleted except the entire container and the amount and size of the files inside the container is mostly³ opaque to other users. In some implementations one can even nest an encrypted container inside an encrypted container for plausible deniability. I think I have seen encrypted containers being used on Chrome OS/Chromium devices stateful partitions, now I remember why. But I’m not recommending Chromium since Endless is supposed to be used offline rather than always connected to high speed Internet and storing private data on computers not owned by you.
You should not assume malice here. Configuring easy and reasonable privacy defaults is difficult (at least to me) and teaching students about privacy appears to be more sensible to me than to expect strong privacy by default, which also comes with the risk of loosing your data if you can’t remember your password and/or lost your token.
eCryptfs and EXT4’s encryption are file based. I think you can enable this in the installer (or afterwards) and as far as I’m aware it decrypts files when the user is logged in with the same permissions as on unecrypted setups (everyone can access files by default), but locks up once the user logs out or locks the screen.
One could still copy the contents and try to run attacks against a weak password or encryption method.
Full disk encryption usually encrypts an entire disk or filesystem to make it all look like noise even if there was no data to begin with. There was nothing to worry about until SSDs with TRIM arrived which cleared unused blocks of thei noise, exhibiting the blocks that actually contain data.
My bad on my first version of this response (now edited), thanks for the feedback. I incorrectly assumed that was Endless responding. I’ll wait to hear back from them also, I just have some pretty emotional and upset users I’m trying to be responsive to.
I do not think there has been an official response from Endless yet. What other posters have pointed out is that the weakness you describe is not at all uncommon. ChromeOS is secure for multiusers because it uses full encryption and a ChromeOS device is specified to have a security chip in hardware. The responsibility for security on an open source *nix based system generally falls to the person implementing it. Multi-user simply means that the system supports more than one user.
Links in lwbt’s post point to a simple method to limit permissions for files and folders.
The Endless team has been very responsive to user input and would suspect you will get a response from them soon after the weekend.
Yikes! This completely caught me by surprise, as I too would have expected home directories to not be world-readable. It appears that some distros such as Fedora are more reasonable and set the home directory permissions to 700 by default, while others such as Ubuntu (at least in my test of Ubuntu 15-10) set the permissions to 755 by default. Since we are based on Debian and share a lot of underlying code with Ubuntu, I suppose it is not surprising that Endless has similar default behavior.
That said, I 100% agree that our current behavior is wrong, and we will fix it ASAP. In the meantime, you can protect any existing user accounts with sudo chmod 700 <username>, but of course any new accounts created will default to 755.
For what it’s worth, I’ve kept the “Shared” account on my own computer enabled for testing purposes, and never imagined that someone would be able to simply log into it and get access to my personal files.
Keep in mind, though, as was noted by others, that the storage device is not encrypted, and thus anyone with physical access to the machine can access any files on the device with some effort, either by removing the storage drive or by booting from a USB drive (though I imagine USB drives might be locked down in a corrections facility).
Thank you @worldpossible for bringing this to our attention!
@worldpossible We’ll be fixing this for Endless 3.1.6 (scheduled for release next week), but in the meantime here is how you can change the default for new accounts…
Thanks Roddy for your insight. I will be waiting anxiously for the new release. We would like to deploy to our population as well. I am also in a correctional environment and would prefer to dual boot for a couple of reasons.
Also noted that the standard user can launch and use the terminal and with the correct command line, can turn items on or off. This seems like another vulnerability that is not good for a correctional environment.
@gwestoby Can you please provide an example of something that can be modified by a standard (non-admin) user from the command line that you are trying to prevent? A standard user without an admin password should not be able to make any changes that impact other user accounts. If there is any such a hole in the security, I think we should tighten that up.
Completely blocking access to the terminal would be pretty difficult, I think. Even if the gnome-terminal app were somehow blocked, a user can get access to a console via Ctrl-Alt-F2. And, if teaching to code is one of the goals of the program, that will become more difficult if the command line is not available.
I logged in as a standard user and went to the terminal and was able to add or delete the facebook app on the task bar by typing ‘gsettings set org.gnome.shell enable-social-bar false’ or add it back by answering ‘true’. Just tried to get in as SU but that is blocked from the standard user. My worry is that with different command line strings, youth may spend some time experimenting with the Terminal until they get into some of the file structure.
Additionally with a dual boot system, the standard user can follow the link to ‘+Other Locations’ to other folders on a dual boot system. This also leaves the Windows OS files unprotected regardless of the security permissions or controls through the Group Policy Editor. I was able to reach down into the c:\windows\system32\oobe\info\backgrounds\ folder and disable the login page background on the windows OS while logged into the Endless standard user account.
@gwestoby For what it’s worth, the social bar feature (Facebook icon on the right of the taskbar) will be going away with the 3.2 release in June, so you won’t have that specific issue any more. But regardless, if you don’t want users going to Facebook, you would have to remove internet access (or set up your router to block access to certain IP addresses).
I would recommend against dual boot systems in such an environment. As you have noticed, in general there is no way to protect files in one OS from the other OS. Another example of what can happen is that someone on Windows could easily modify the /etc/shadow file on Endless to reset passwords for users (and while I don’t know the details, I imagine someone could reset Windows passwords from within Endless).
If having a dual-boot system without access to Windows files from Endless is a requirement, that is something that could possibly be achieved by contracting work through our Solutions team to provide a custom image build. Perhaps there are ways that you can set up permissions to avoid letting standard users mount the Windows drive from within Endless without a custom image build, but I know that we intentionally tried to make it easy to access the Windows drive, so I’m not sure how easy it would be to disable that on an existing deployment.
As for blocking access to the terminal, I don’t have any suggestions on how to do that. Gnome-terminal is a core component of the operating system OSTree and cannot be uninstalled (like a flatpak app). So, even if we provided a means to block it from showing up in the app center, the user could always hit Alt-F2 and type gnome-terminal (or simply search for term on the desktop search). And, like I previously mentioned, even if gnome-terminal were blocked, there is still the TTY console. I really think that the best approach is to make sure that anything that really needs to be protected is properly locked down, and not assume that hiding the terminal provides any real security.
@gwestoby It turns out that accessing the Endless files from Windows should only be possible by an admin user on Windows. But, as you have seen, we made easy (probably too easy) for Endless users to see Windows files.
As I thought about it some more, I realized that there is a pretty serious security concern with the way things currently are implemented. By default, we create a “Shared” account which requires no password and has only normal user permissions. But, since the Windows drive is accessible to a standard user, someone could walk up to the machine, log into the shared account, and read personal files on a Windows account (or make modifications to Windows files, as you mentioned).
We are evaluating our options here, and will likely lock things down better in a future release so that only admin users on Endless can access Windows files.
Thanks for the update. I don’t necessarily think we need to have the terminal locked down. As you mentioned, that is a basic requirement to learn coding. I was a little concerned about being able to access the Windows OS from the Endless standard user but I think a lot of this can be circumvented quickly by being able to block the “other locations” for standard users profiles while still allowing Admins to access the other locations.
I have not yet tried to access the Endless file structure from within the Windows environment. Might try that tomorrow.
Also I am not opposed to wiping the drive clear and installing Endless. But I do have some specific modules that will need to be installed through Endless on the desktop. The beauty of the dual boot is it would require two separate user accounts to access either OS. We can put content that is required on the Windows OS with very little other content to get the student access to the beginning work for the cottage and once they complete that, they can have full access of the Endless content by unlocking the other login.
I will try to get back to you sooner but today and yesterday we are wrapping up a statewide data collection process and I am overseeing this. So I have a few plates in the air, if you know what I mean… Thanks again for your insight and recommendations.
@gwestoby I think we’ll be able to block the non-admin access to the Windows partition very soon, and then I think a dual-boot can be made reasonably secure after all. I’ll let you know when I can confirm which release will have this fix.
Blocking the locations from the UI doesn’t block the underlying capability to access the Windows drive (eg by running the equivalent operations from the terminal). We’ll tweak the policy a little bit so that like the other “system” drives (like HDDs, SSDs, etc, rather than USB keys) this type of access is only available to administrator users regardless of whether they are using the file manager or the terminal. The only difference will be with the Windows C: drive, the Administrator won’t need to enter their password again.
This c:\endless\endless.img file should be pretty well-protected - it’s flagged as hidden/system/read-only, and has ACLs set to prohibit read/write by all users (including administrator users, to prevent accidental damage) - so if you want to futz with it at all, you need to be an administrator to even find it and change the ACLs to modify it.
That is great news! I am excited about getting a fairly secure dual boot up and running. It essentially gives us an opportunity to allow the youth to log into the Windows OS with very limited access. Once they have completed the required programming on the Windows OS, we can then get them set up on the Endless OS with all the associated content.
Having the two OS’ files accessible by Admin only is great news and I also tried to make some changes from the Terminal as a standard user and was not able to successfully change anything. I was able to add or remove the Facebook icon on the task bar but as stated earlier, it is not a factor because these devices will not have internet access.
We are very excited to get these up and running on our living units.
Just installed Endless 3.1.7. Real stable OS and most of the vulnerabilities are gone!
Dual boot on Windows 7 pro very smooth.
Admin still has access to Windows 7 file structure.
Shared account does not have access to Windows files at all now.
Shared account does not have access to all home folders, just their account and the shared account folder.
One question: when it upgraded from 3.1.6 to 3.1.7, the dual boot lists both versions along with the Windows 7 option for booting. Can I easily remove the 3.1.6 option from the boot screen without altering the MBR? Very nice and smooth.
Great working with the Endless team at the Hack-a-thon in Woodburn yesterday. Awesome team!
One question: when it upgraded from 3.1.6 to 3.1.7, the dual boot lists both versions along with the Windows 7 option for booting. Can I easily remove the 3.1.6 option from the boot screen without altering the MBR?
This is because when we run an upgrade, we keep the previous version of the OS around. After rebooting into the new version, you can remove the previous one by hand. First, list the deployed versions:
$ ostree admin status
* eos [long hexadecimal string]
...
eos [different hexadecimal string]
...
The asterisk indicates the booted version. You can remove the other one with:
$ sudo ostree admin undeploy 1
But next time you upgrade, there’ll be two options in the menu again.
In Endless OS 3.2, the older version will be moved into an Advanced ... submenu on the GRUB screen, and on BIOS machines the Endless OS GRUB menu will be skipped entirely (we will add Endless OS to Windows’ boot menu, rather than the other way round as we do currently). So if you are concerned about this from an aesthetic perspective, the best thing to do is wait till Endless OS 3.2 is released and then reinstall it. (Unfortunately, we do not currently upgrade the bootloader when upgrading the OS.)
Thanks for the information. Very much appreciated. I will log in and remove the other eos to remove the confusion for our end users. Looking forward to version 3.2. Great product and very responsive.