[ebsmount] enabling of ebsmount has security concerns and side effects
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| ebsmount (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: cloud-utils
Per "docs/README" in the package
| - Once a filesystem is mounted, EBSmount will execute scripts in
| alpha-numeric ordering located in MOUNTPOINT/
|
| - This provides a very powerful mechanism. In its simplest form, the
| user might want to symlink the mountpoint to a more accessible
| path, for example:
As it is right now, the following can result in unexpected or malicious behavior:
i.) a mis-typed 'ec2-create-volume snap-abcdefg && ec2-attach-volume vol-abcdefg' could result in running a 3rd parties code as root on your system.
ii.) if a partition on a ebs volume mounted at anywhere (/var/log, or /home) can be written to by non-root, a .ebsmount dir could be created by a non-root user, and upon next reboot (or attach/detach) their code would be executed as root
Additionally, Mounting partitions by default has the unfortunate side effect of breaking a normal administrators use of "attach volume, ssh to instance, mount volume". In that scenario, the final 'mount volume' would fail as it is already mounted. Possibly worse, existing solutions based on udev rules and automounting would break.
| affects: | cloud-utils (Ubuntu) → ebsmount (Ubuntu) |
| Alon Swartz (alonswartz) wrote | #1 |
| Alon Swartz (alonswartz) wrote | #2 |
| Logan Rosen (logan) wrote | #3 |
Version 0.93 [1] solves the hooks issue.
As discussed in the changelog, execution of hooks have been disabled by default. To enable them, RUNHOOKS=True needs to be set in /etc/ebsmount.conf. Additionally, hook scripts won't be executed if they are not owned by root (uid and gid).
This release also sets MOUNTPOINT in the environment when executing the hook scripts for convenience. Also, ext4 has been added to FILESYSTEMS for out-of-the-box support.
[1] https:/