On Thu, Apr 2, 2009 at 3:06 AM, J.C. Roberts <list-...@designtools.org> wrote: > On Wed, 1 Apr 2009 21:24:16 -0400 Nick Guenther <kou...@gmail.com> > wrote: > >> On Wed, Apr 1, 2009 at 10:48 AM, J.C. Roberts >> <list-...@designtools.org> wrote: >> > On Wed, 1 Apr 2009 04:46:10 +0000 Jacob Meuser >> > <jake...@sdf.lonestar.org> wrote: >> > >> >> On Tue, Mar 31, 2009 at 07:13:33PM -0700, OpenBSD wrote: >> >> > Hello >> >> > >> >> > Could somebody please tell me how to use a dvd-rw as user? >> >> > I'am trying to install Slackware using qemu, and the dvd does not >> >> > work properly, it works well as root. I've tried adding the user >> >> > to operator group, users group, and declaring it at fstab without >> >> > optimum results. >> >> >> >> by default root can read and write /dev/rcd0c. operator group can >> >> only read. >> >> >> >> you need to be able to write to /dev/rcd0c to put a filesystem on >> >> a cd/dvd. >> >> >> >> you can change the permissions on /dev/rcd0c or use sudo. >> > >> > Using sudo is a great way to handle this situation, but this depends >> > on how much you trust the user, and whether or not you can properly >> > configure /etc/sudoers with visudo. >> > >> > NOTE: Jake only said "change the permissions" but he did not say to >> > change them permanently on disk. Of course, changing permissions >> > permanently on disk is an option, but in many situations it is not >> > the best option. >> > >> > If as root you fumble-finger the chown/chmod command on your >> > devices, stuff a user into the wrong group, or don't fully >> > understand all the esoteric issues involved in device permissions, >> > you could easily be in a world of hurt. >> > >> > If you really want to go the route of changing permissions on a >> > workstation, the best way to do it is using the existing features >> > available /etc/fbtab to change permissions on devices automatically >> > and temporarily at user login and logout. See man fbtab for details. >> > >> > This exact situation of an unprivileged local user needing access to >> > devices is the reason why fbtab exists. >> > >> >> Reading fbtab(5), it seems that it changes the device permissions >> whenever any matching user logs in. So what happens if two users log >> in (say, one on the first virtual term, one on the second)? Does the >> second get control of all the devices and the first is just out of >> luck? > > It depends on how you configure things. It's just a chmod, so you could > set the permissions however you want (owner/group/everyone). At times > you would *want* the other guy to be out of luck. > > The tty(4) used to login, is the trigger for fbtab to the change the > permissions. If you look at your /etc/fbtab file, you'll find you're > already using it. > > If you log into the first virtual terminal (i.e. the default), you're > on /dev/ttyC0. If you log into the second virtual terminal, you're > on /dev/ttyC1, and so on. Though they are called "Virtual Terminals" > and you've got a number of them, they are, in essence, device files > associated with "hardware terminal ports." Yes, the names, hardware > versus virtual, do seem a bit contradictory until you read `man 4 tty` > and think about it.
When I get back to my BSD box I'll have to remember to see who owns what if I login as one user on ttyC0 and a different one on ttyC1. > The Virtual Terminals (normally) all use the same single of user > interface equipment (keyboard, mouse, ...), but the equipment is only > tied to one virtual terminal at a time. Yep, by switching virtual > terminals, you're basically reassigning control of the equipment from > one hardware terminal port to another. > > You might be doing something highly improbable, namely you are > successfully running a "Hydra System" (i.e. multiple keyboards, mice, > monitors, ... all connected to one system) -- If you've got that > working, please tell me how. (; -- In this case you could have two > different people logged in *locally* via UI equipment. Sadly, I do not > recall how tty(4)'s and/or virtual terminals are assigned on a hydra > system. I'm fairly certain it still involves the typicall TTY > "dial-in" port waiting for a connection/login (via getty), but I do not > recall (and can't find) the details on how the hardware gets assigned. > > In contrast, if you log in remotely via ssh, you use a "pseudo > terminal" (pty(4)), so the local keyboard, mouse and whatever are not > assigned. Again it might seem contradictory, but if you're running the > X Window system, and you start an xterm window, the xterm is also > assigned a pseudo terminal --the reason being is the keyboard, mouse > and whatnot are *already* tied to the "Graphics Virtual > Terminal" (/dev/X0 typically assigned to CTRL-ALT-F5) and the X Server > is responsible for passing keystrokes to the xterm window. > > Yep, when you start X Windows, you actually switch virtual terminals, > so the keyboard, mouse, monitor and whatever get reassigned to it. If > you look at the default /etc/fbtab, you'll see it handles the > reassignment of the your mouse device (/dev/wsmous /dev/wsmouse0). I do > not personally know why only the mouse is reassigned to the X/Graphics > virtual terminal via fbtab and your keyboard and monitor are not, but > there is probably a good reason for it... ---I like to believe said > good reason is sitting quietly, waiting, in a very large pile of good > reasons that I do not know and need to discover. (; > > You've now got the basics of "login devices" (tty's/pty's), and you > understand that using any one of the login devices can cause fbtab to > change permissions on the system. At this point, you should see the > potential "conflicts" you could create such as granting write access to > the CDROM drive to two loging devices, and hence two different users. > > This supposed "conflict" is mostly imaginary. If you log in as root on > two separate virtual terminals and try to format the one floppy disk on > the system, guess what will happen? -Yep, one of them will get a > "device busy" error and need to wait until the other is finished, so in > most cases, it will not be a big deal. Om info nom >> It seems a lot simpler to just chmod g+w on any devices you find >> you need and make sure you're in the operator group (though don't >> chmod g+w /dev/*, I did that once and things broke very badly I seem >> to recall, though I don't remember details since I was more like >> "shitshitfixfix"). >> >> What's the risk in doing it this way? The only thing I can see is that >> if someone breaks into your account they can burn CDs remotely > > If you're using the local tty's (/dev/ttyC?) to grant write access to > the CDROM, you have a lot more to worry about because said attacker who > "breaks into your account" has physical access to the machine. > >> (or overwrite any unmounted partitions) > > I see no reason to change hard disk permissions at all. The default > permissions are correct just the way they are, and they prevent this > kind of nonsense from unprivileged users. > > $ whoami > jcr > $ pwd > /home/jcr > $ mkdir jcr-mnt > $ mount /dev/wd1a jcr-mnt > mount_ffs: /dev/wd1a on /home/jcr/jcr-mnt: Operation not permitted > $ > My reason is that kern.usermount=1 is not much use unless your user account can write the harddrive devices. chmod g+w /dev/rsd* is a lot less hassle than fbtab (not neccessarily just laziness! Reduced complexity => easier to maintain => less security problems). mount(8) (where I learned about kern.usermount) doesn't mention fbtab, so I just did what seemed, in lack of any other guidance, to be the most elegant thing. Anyway, I only put my user account in operator, and it's not like I run any network facing daemons as that ((that's secure-enough, right?)). > >> while you're not logged in which >> is obviously so much more dangerous than someone breaking into your >> account while you are logged in. >> >> -Nick > > That is a bold statement, particularly with the "obviously" you tossed > in there, and with any bold statement, I would like to see your proof! Yeah yeah, okay. I knew I was being snarky. But look at all the information it netted me! (thank you) > I'll save you the effort; there is no proof. > > The thing you over-looked is the fact I said "local" user above. It's > very useful for allowing read and/or write access to removable media > (floppies, CD, maybe flash-drives if you're feeling generous) and/or > sound/video devices without giving a user user excessive permissions > (sudo and/or groups). Since the user has *physical* access to the > machine in order to just use the removable media, the system is, by > default, insecure. If a talented attacker has physical access to a > machine, it's game over, you lose. > > Equally, if a talented attacker *only* has access to an unprivileged > account remotely, it's still game over and you've still lost. Of course > some moron on this list will say, "But I removed the compiler from the > system so they can't write exploits," and everyone else here will sigh, > mutter "fidiot" under their breath, and laugh... publicly. If said > moron persists with his misconceptions, all the rest of us might get > lucky enough to see beck@ put on his magical +5 Mullet Wig of Ranting > and entertain us for a while. Well I know better than to remove the compiler, but just so I don't suddenly get overly paranoid (since I've given out accounts to some of my friends): this "game over" you speak of revolves around the attacker finding a way to get a setuid binary to run some shellcode or similar, right? > > The situations where fbtab is very useful revolve around enabling an > employee to do their job on a workstation, and doing so without granting > excessive access to the machine. If said employee is actually a > talented attacker in disguise, then you are, undoubtedly, hosed. I still don't see this. fbtab gives permissions when said employee logs in. Therefore, said employee can do whatever they want. All fbtab does is force said employee to be physically at their station to be able to do whatever they want. Otherwise, how is this any different than putting said employee in 'operator'? Or if operator is so bad, how is it any different than using some other less privileged group? (I'm not trolling, I'm trying to understand the flaw, if any, in what I've done). > The other situation where fbtab is very useful is when you do not trust > *yourself* not to make a complete mess of your device permissions. If > with excessive permissions you've ever executed the wrong command, or > wrote a bit of code that goes running off into the weeds, and you've > basically destroyed your OS installation by your mistake, then *you* > are a perfect candidate for using fbtab... --Yes, that means every > single one of us... including me. > > $ whoami > jcr > $ cdio tao install45.iso > cdio: Can't open /dev/rcd0c: Permission denied > $ See this is another thing that annoyed me. I shouldn't have to *sudo* just to burn my latest music CD. It should *just work*. I don't see how fbtab will protect me from myself. If I have permission to do something and I do it and it turned out to be a mistake then I'm -- hosed. I've found myself getting so used to running sudo that it's supposed guard against slippery fingers is wearing off. > The security implications of permissions on devices is an extremely > complex topic. I probably understand maybe 20-30% of what I'd *need* to > know to write/set them from scratch. Lucky for you, there are people a > lot smarter than me who set all the default permissions up for you. Is it that complex? It's nowhere near as difficult as NTFS ACLs. There's, what, only 12 bits of information per file? If you can read it you can read it, if you can write it you can write it. In your 20%, what are some of the (presumably external) things that interact to make devices permissions so complex? > If you decide to mess with them without understanding what you are > doing, then you do so at your own peril. Understood, of course :) > On the other hand, if you want to > make an informed decision to grant read or write access to the CDROM > drive or whatever of a workstation used by an employee, you now know > you have options other than granting/requiring sudo or blindly tossing > users into over-privileged groups or permanently changing your default > device permissions on disk. Still from my (still new-to-unix even after 4 years) impression, it seems a lot easier to audit who's got write access without the permissions changing. Static data tends to be easier to analyse (a la lisp), right? > -- > J.C. Roberts Well thank you for the insight. I don't have any employees to worry about, just me and my friends who come over and want to hop on MSN sometimes. If they start booting into single user or pulling my harddrive I think I'd notice. -Nick
