2

Consider the following situation:

/dev/sda1, /dev/sda2, /dev/sda3 are 3 partitions of the /dev/sda disk.

Ubuntu is installed on sda1 and /home mounted on sda2.

Only one user foo on Ubuntu system so its home folder is /home/foo on /dev/sda2.

I'm going (and I know how) to install another distro (e.g. a Lubuntu) on /dev/sda3 with only one user blah.

My question is:

How to do that in such a way that the user blah can not access neither mount the partitions /dev/sda1 and /dev/sda2?

Is it enough to remove any entry referencing it on fdisk?

I'd like to make those 2 partitions only available for the user foo on Ubuntu.

I'd like that user blah wouldn't have access even using sudo.

My idea is, while installing the new distro on sda3 just don't ask to mount the other partitions so that the disk for the new distro is only sda3.

peterph
  • 30,838
Sigur
  • 2,431
  • Will user blah have physical access to the machine? If so, make sure they can't boot up a Linux live CD/DVD/USB. – PM 2Ring Dec 19 '14 at 07:21
  • @PM2Ring, yes, this is a problem. I can not deny them to use usb sticks. Maybe I could use a pass for setup menu and remove the usb boot option. What do you think? – Sigur Dec 19 '14 at 09:54
  • Yes, you need to put a password on the BIOS / UEFI and remove the ability to boot from USB or CD/DVD. – PM 2Ring Dec 19 '14 at 11:08

2 Answers2

2

It depends on if blah is a root on your sda3 installation. If no:

By default can only root mounting anything, so you don't need even get out them from the /etc/fstab. Only what you should check:

  1. They need the noauto flag (to not mount them on boot)
  2. And shouldn't have the user flag (or they were mountable by user).

If he is a root, or have (or can make) root privilege:

Then the situation is much more problematic. Essentially, root can do anything on a system, and if your partitions are there, they are readable, there is no direct way to prevent that. Although there are some indirect thing which you can maybe do (if they are workable by you, it depends mainly on your circumstances).

  1. You can encrypt sda1 and sda2. Encrypting root partitions needs normally a little bit of extra work, but most distros support that. They keyword on them you had to start: luks. Encryption doesn't prevented the destroying of these partitions, but it prevented their reading. I must also mention, that with physical direct access even this doesn't prevent everything, but it could be probable okay.
  2. You can use the sda3 installation in some of a virtual machine solution. On the sda1/sda2 install you give him only client access, from the virtual machine you deny the direct sda1/sda2 access, and sda3 will run in a vm. If you limit the vms premissions (as root on the sda1/sda2), you limited his privileges even as a root on sda3.
peterh
  • 9,731
  • Thanks for some explanations. The user blah will be created during the installation. The default is not to be a root, right? After I install I can check its permissions. When you say if the user is a root you are talking about if it is on sudoers? – Sigur Dec 18 '14 at 20:17
  • 1
    @Sigur Yes, by default he won't be a root, although there are some distro who makes such users the possibility to sudoing to root. This was originally not in unix/linux, it was only developed to make things simper for people coming from the w$ world. If there is some such thing, you should change this in some system setting. Then the best solution were if you would create 2 different users: the first, during the installation, for you, and you created a second user, this time as really as a simple user, and gave only his password to him. – peterh Dec 18 '14 at 20:20
  • @Sigur Yes, if he can make himsef to root, he is essentially root. If he can sudo, because he is in the sudoers, nothing can prevent him to read you sda1 and sda2 partitions, with the exception if you can limit somehow the skills of the whole sda3 machine (either by encryption, or by virtualisation (there are yet some tricky ways, for example grsecurity)). – peterh Dec 18 '14 at 20:22
  • So, I guess that create an user to me and then a simple user is the best option. But is it possible to give specific permissions to the simple user? For example, it would be good if it could use terminal to install programs via apt-get. Otherwise every time they will call me to install something (they are my students and no problem with install soft or update TeXlive, for example). – Sigur Dec 18 '14 at 20:42
  • @Sigur The main problem, that if you don't give them root permission, but the have physical access, they can elevate their physical access to a root permission (for example, by booting from a live cd). There is no simple protection against that. In very tricky (and rich) companies there are virtualized client clouds and embedded desktops contacting them. – peterh Dec 18 '14 at 20:50
  • 1
    @Sigur Are they hackers or not? Are they cooperative or not? Do you want protection against everything, or you have only some undergrad stundents and won't weekly reinstall because they uninstalled bash again? Or you only want your wife to not reach your "private" browsing history? Your problem probably can be solved, but it depends a lot on your circumstances, and these circumstances you didn't say. – peterh Dec 18 '14 at 20:53
  • so the situation is becoming complicated. They are not hackers and I'd like to give them permission to update or install some programs. But I don't want them opening my dropbox folder on Ubuntu. – Sigur Dec 18 '14 at 20:55
  • Is it possible to encrypt only my home folder? – Sigur Dec 18 '14 at 20:57
  • 2
    @Sigur Somehow yes, but I can't remember. If you want surely a such thing, ask this in another question. But in your place I even didn't do that. Instead of that, my home (on sda2) were only encrypted with luks, and any other thing (included the home of the other users) were on sda1. There were no need to a multibooted system. But this works only if they are cooperative and won't hack (for example, a hacker could install some spying daemon as root, and steal your dropbox folder remotely, when you are logged in and mounted your crypted partition). – peterh Dec 18 '14 at 21:00
2

There are several things mixed here mounting a filesystem by user and superuser, accessing files on a mounted file system and accessing the data on the "raw" device.

  1. mounting a file system

    root can always mount a file system, provided he can access the device that carries it - which it can when the kernel recognizes it. Users are only allowed to mount a file system, if it is referenced in /etc/fstab and either user or users is among the options for that entry (read the mount(8) man page).

  2. accessing files on a mounted filesystem

    Again, traditionally root can always access any files on a mounted file system (unless a patched kernel is used of course). Users are subject to file permissions.

  3. accessing data on the raw device (e.g. /dev/sdaX)

    Same as with files above. Users usually don't have permissions to access raw block devices, root does.

Hence if you want to prevent user in the second system from mounting or accessing data on the mounted file system used by the first operating system, edit /etc/fstab and apply permissions appropriately. Remember, that permissions on a file system are bound to UIDs/GIDs not tu user/group names - thus if user foo from system 1 has the same numeric UID as user bar from system 2, they have exactly the same right when accessing files.

If you want to make sure that the file system can't be accessed even by a superuser, encryption is the only way to go.

Or you can run the second system in a virtual machine on the first one, giving it access only to parts of the hard drive you want. There are various ways to set it up like this, unless you'd want to be able to boot the second installation on bare metal as well, you can just give the virtual machine whole /dev/sda3 as its /dev/sda.

One last note (especially for users of Ubuntu and similar distributions that cripple sudo configuration by allowing all users run everything as administrators by simply prepending sudo to their commands) - "access through sudo" is a misplaced term - you either have or have not some (or all) privileges that are usually associated with the root (UID 0) user. You can get the same privileges with su.

Community
  • 1
peterph
  • 30,838