With an attacker mindset, I wouldn't give users persistent access to the disks group. udev creates disks in /dev with the disk group, and r+w group permissions. So, if I want to screw around with the root filesystem, I can now go indirectly via which ever /dev/<disk><part> has the root fs and monkey with the bits on disk. This is now a continuously open hole for those users granted into that group. With sudo, practically speaking, most personal computers are single owner, so the users already have it. And then there is an explicit privilege escalation for the one task, and no persistence of unneeded privilege. I feel your developer is making the choice of convenience over security and explicit/relatable action of the user. On 2/17/20 4:42 PM, John Sellens via talk wrote:

The developer seems to be insisting on an answer, rather than a need. The need is to allow easy writing when appropriate.

Consider a wrapper script that uses sudo to call the actual command.

And then set sudoers(5) to allow appropriate people to run the command as root without a password.

That means that it's easy for the user, and access to the disk devices is only provided through the (presumably) tested and well-functioning command.

Remember: you can solve any problem in computer science with another level of indirection.

I suspect that there's a way via udev or dbus to accomplish the appropriate thing. But I'm not smart enough for that.

Hope that helps!

John

On Mon, 2020/02/17 04:28:52PM -0500, Stewart C. Russell via talk <talk@gtalug.org> wrote: | So I'm working with a developer making a simple cross-platform graphical | program to write Raspberry Pi OS images to SD card. This is meant for | beginners to use. The developer is adamant that their program doesn't need | to run under 'sudo' but that every user should be added to the disk group | instead. | | This means that every user can write directly to system disk devices at any | time. The Debian-based systems I use don't add regular users to "disk". Is | it reasonable/common for regular users to be set up this way? | | cheers | |  Stewart $(export HAVE_ACCIDENTALLY_OVERWRITTEN_ROOT=1) Russell | | | | --- | Post to this mailing list talk@gtalug.org | Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

-- Scott Sullivan

Hey, thanks to all who responded. I'm sticking with merely "bad idea", as it would also give the user block-level access to everyone's secret files. I know sudo already does this, but one has to manually clunk into that mode. Though there are still plenty of Raspberry Pi users who 'sudo ls', for some reason. On 2020-02-17 7:23 p.m., Chris Tyler wrote:

Wouldn't it be better to use SGID to enable access to disk devices only for the duration of that program's execution?

Author claims it's not possible. The program was written as a reaction to finding out that balenaEtcher (https://www.balena.io/etcher/) "phones home" with usage data. If true, this is unfortunate, because Etcher fixes all the fiddliness of using dd as root, it's truly cross platform, and avoids the Windows unzip bug. No-one's yet identified what exactly Etcher phones home yet, but that hasn't stopped the heat, light and fury of a Free Software Cause in the making … The new program's quite usable for now (even if you have to run it sudo) and appears to be cross-platform too. It's also a lot smaller than Etcher, which is an Electron app. Source repo is here: https://gitlab.com/bztsrc/usbimager

On Thu, Feb 20, 2020 at 04:11:47PM -0500, Chris Tyler via talk wrote:

Stewart, I'm having troubles understanding the author's reply to the SGID suggestion. What I was proposing was to set things up with a command like this (executed just once):

BINARY=/path/to/binary ; sudo chmod 02711 $BINARY ; sudo chown root:disk $BINARY

...Which would mean that the user would have their effective group ID changed to 'disk' only while the binary was running. This means that, during program execution, it would be have the same level of access as if the user belonged to the 'disk' group; however, this would drop back to their previous group membership when the binary exited. As a bonus, you don't have to change the system group memberships. (The program in question should, of course, guard against writing to the wrong device while it's running, and prevent shell-outs).

It also means any user running the program has that access, not just users in group disk. That may be considered better or worse. I suppose the program could check that the user belongs to some other group meant for this program, but then it gets even more complicated. -- Len Sorensen

A helpful addition would be to bracket the part of the program that does disk IO with setgid(), just like one brackets setuid code. --dave On 2020-02-20 4:11 p.m., Chris Tyler via talk wrote: Stewart, I'm having troubles understanding the author's reply to the SGID suggestion. What I was proposing was to set things up with a command like this (executed just once): BINARY=/path/to/binary ; sudo chmod 02711 $BINARY ; sudo chown root:disk $BINARY ...Which would mean that the user would have their effective group ID changed to 'disk' only while the binary was running. This means that, during program execution, it would be have the same level of access as if the user belonged to the 'disk' group; however, this would drop back to their previous group membership when the binary exited. As a bonus, you don't have to change the system group memberships. (The program in question should, of course, guard against writing to the wrong device while it's running, and prevent shell-outs). -Chris On Tue, Feb 18, 2020 at 8:27 AM Stewart C. Russell via talk <talk@gtalug.org<mailto:talk@gtalug.org>> wrote: Hey, thanks to all who responded. I'm sticking with merely "bad idea", as it would also give the user block-level access to everyone's secret files. I know sudo already does this, but one has to manually clunk into that mode. Though there are still plenty of Raspberry Pi users who 'sudo ls', for some reason. On 2020-02-17 7:23 p.m., Chris Tyler wrote:

Wouldn't it be better to use SGID to enable access to disk devices only for the duration of that program's execution?

Author claims it's not possible. The program was written as a reaction to finding out that balenaEtcher (https://www.balena.io/etcher/) "phones home" with usage data. If true, this is unfortunate, because Etcher fixes all the fiddliness of using dd as root, it's truly cross platform, and avoids the Windows unzip bug. No-one's yet identified what exactly Etcher phones home yet, but that hasn't stopped the heat, light and fury of a Free Software Cause in the making … The new program's quite usable for now (even if you have to run it sudo) and appears to be cross-platform too. It's also a lot smaller than Etcher, which is an Electron app. Source repo is here: https://gitlab.com/bztsrc/usbimager --- Post to this mailing list talk@gtalug.org<mailto:talk@gtalug.org> Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk --- Post to this mailing list talk@gtalug.org<mailto:talk@gtalug.org> Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dave.collier-brown@indexexchange.com<mailto:dave.collier-brown@indexexchange.com> | -- Mark Twain CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.

On Feb 21, 2020, 10:14 AM -0500, mwilson--- via talk <talk@gtalug.org>, wrote:

Would it be as simple to change the permissions on the particular drive, and then just let the users have at it?

eg. sudo chmod a+rw /dev/mmcblk0

To be safe, you would have to disallow mounting of filesystems on that drive (or any other drive with the same media) because someone could make a filesystem on that media, create a SUID program in that filesystem (through raw I/O), mount the filesystem, and then run the SUID program. If I recall, there is a flag you can set on mount that prevents running of SUID programs on the filesystem…. that would also suffice. ../Dave

| From: Lennart Sorensen via talk <talk@gtalug.org> | | On Thu, Feb 20, 2020 at 04:11:47PM -0500, Chris Tyler via talk wrote: | > Stewart, I'm having troubles understanding the author's reply to the SGID | > suggestion. What I was proposing was to set things up with a command like | > this (executed just once): | > | > BINARY=/path/to/binary ; sudo chmod 02711 $BINARY ; sudo chown root:disk | > $BINARY | > | > ...Which would mean that the user would have their effective group ID | > changed to 'disk' only while the binary was running. This means that, | > during program execution, it would be have the same level of access as if | > the user belonged to the 'disk' group; however, this would drop back to | > their previous group membership when the binary exited. As a bonus, you | > don't have to change the system group memberships. (The program in question | > should, of course, guard against writing to the wrong device while it's | > running, and prevent shell-outs). Sounds better than alternatives. It's the (original) UNIX way. | It also means any user running the program has that access, not just | users in group disk. That may be considered better or worse. No, it means: any user can run that program and that program will be able to do serious things to any disk. As Chris said, the program must be written carefully and defensively. What kinds of restrictions make sense? Here are some that come to mind: - make sure that the disk is a USB stick or SD card - make sure that the device isn't currently mounted. - A possibly risky option that would be user-friendly would be to offer to unmount any mount. If the code were to unmount, it should drop privilege before attempting an unmount. This is to prevent the user from unmounting a drive that he otherwise could not. - perhaps: make sure that the user is logged onto the console (Fedora used to have a group for this.) - as much of the program as possible should run without group disk privilege. I think that this is what David Collier-Brown was saying. | I suppose the program could check that the user belongs to some other | group meant for this program, but then it gets even more complicated. That would be a possible example of being careful. Unfortunately, that isn't easy for newbies to arrange. ================ "sudo command" is a bit scary. Is "sudo -g disk command" a bit better?