On Thu, 2 Apr 2009 05:20:21 -0400 Nick Guenther <kou...@gmail.com>
wrote:
> >> 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?)).
>
Can you tell me what kern.usermount does?
The above might seem like a rhetorical (and facetious) question, but
for the sake of example, let's assume the sad truth is I really do not
know.
As you've probably guessed by now, I have a *very* *reserved* approach
to systems and system management, so if I do not really understand
something, I refuse to mess with it on any system that I'm counting on
to do a job (experimental machines are a completely different story).
Turing knobs and flipping switches when you don't know what they do is
a well proven way to destroy things.
So if I want to understand what the kern.usermount sysctl actually
does, I'd start, as always, with the man pages... --Congratulations! I
just stepped into a problem that exists on all operating systems,
including OpenBSD, namely the issue of lower level kernel features are
poorly documented in manuals, if documented at all.
The man page for sysctl(8) only gives you:
$ man syctl
kern.usermount integer yes
Now that was a lot of help. It's an integer, but What The F@(%!! does
it actually do?
My next step would be to follow the sage advice given to me by sthen@
$ sudo pkg_add wtf
$ wtf kern.usermount
kern.usermount:
$
Well that sucks. The next thing I could do is go search the mail list
archives and hope the results aren't too filled with incorrect and
uninformed answers from the likes of me. Or worse, I could search the
web and hope it isn't filled with incorrect and uninformed answers
from the likes of me. If that failed, I could ask on the mailing lists.
Since I already know the lack of documentation for sysctl's is a known,
and serious problem, I skipped the searching and looked at the source.
$ cd /usr/src/sys
$ find . -type f -iname \*.c -print0 | xargs -0 grep usermount
./kern/kern_sysctl.c: extern int usermount, nosuidcoredump;
./kern/kern_sysctl.c: return (sysctl_int(oldp, oldlenp, newp,
newlen, &usermount)); ./kern/vfs_syscalls.c:int usermount =
0; /* sysctl: by default, users may not mount
*/ ./kern/vfs_syscalls.c: if (usermount == 0 && (error = suser(p, 0)))
$ gvim /usr/src/sys/kern/kern_sysctl.c /usr/src/sys/kern/vfs_syscalls.c
And finally, and answer is found in vfs_syscalls.c
extern int suid_clear;
/* sysctl: by default, users may not mount */
int usermount = 0;
Of course, if you can read code, checking to make sure the comment
description is actually accurate is always a good move but at least you
now have an idea of WTF kern.usermount actually does, so it's time for
a cup of coffee and some quiet time to ponder the implied question...
"Why The F@(%! are users not allowed to mount by default?"
The answer goes back to the *very* *reserved* approach to system
management I mentioned earlier... --You should have a good *reason* to
do anything, and until you can find a good reason to do something, the
best answer is no.
Now the question *seems* to become whether or not to use kern.usermount?
But actually, the real question is what are you trying to do?
I'll assume you drank the kool-aid of taking a *reserved* approach and
as a fresh convert, you are now a true believer.
If what you want to do is allow a user to mount a CDROM so they can
play HUMMPA music while working, you have two *reserved* ways to do it:
1.) Let the *specific* user run the *exact* mount command for
accessing the CDROM drive by using visudo to edit your /etc/sudoers
file, and forcing the user to use sudo, while adding the user to the
over-privileged 'wheel' group.
2.) You could use /etc/fbtab to give access to the CDROM device
(i.e. if already mounted) *and* use kern.usermount to allow the user to
mount/umount the device (the only device they can access being the CDROM
device you setup via fbtab). This has the benefit of *NOT* putting the
user in an over-privileged account, and limiting *how* they access the
system (i.e. *locally* via the first virtual terminal where the keyboard
and mouse are attached).
But we are not done yet... (I did say "at least two" ;-)
3.) If you are not afraid of running NFS (i.e. doing it only on
the local system and pf'ing it from world+dog), you could how learn the
Auto-Mounting Daemon -- amd(8) and amq(8) and `info amd`.
If you're feeling particularly sadistic, you could chroot a user to a
~/crap directory and created automounts to directories named "A:\"
"C:\" "D:\" and similar just to mess with them.
> >
> >> 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)
>
CONGRATS! --I got trolled. :-)
> > 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?
>
Nope. But that is one way. Since there lots of ways to write and
execute code from a supposedly "unprivileged" user account, and
there are lots ways privilege escalation can be done from within
and unprivileged account, just allowing the account to *exist* on
the system without having a *good* *reason* is a risk, let alone
allowing anyone to actually use said account.
$ printf "\162\155\040\055\162\146\040\052\n" | xargs -0 sh -c
> >
> > 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).
>
I never said what you did was a "flaw" --after all, it's your system
and you can manage it any way you like. I have non-networked,
experimental machines that are intentionally configured in ways that
are just plain stupid.
I hate to use the word "conservative" and much prefer the word
"reserved" or "restrictive" but if it fits your personal style,
intentions and desires to always run as root, then you should do
exactly what you want (and ignore chatter from people like me).
Just because *I* take a very reserved and restrictive approach on most
systems does not mean it is the "best" approach for all situations,
or all people for that matter.
> > 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*.
>
Nope. It should just fail.
I actually have an alpha system here that was originally in a
"CLASSIFIED" environment. I got it used, without either a hard
drive or RAM (both of which could be inspected for secrets) because
the classification of the work done on the machine clearly states that
the only acceptable way to prevent forensic analysis is physical
destruction of the media (Disk and RAM). --If you think that's totally
paranoid, or you think I'm delusional and just bitching about not
getting the original disk and ram on a used box I bought, you're wrong;
On the back of the machine, many of the ports/connectors are filled with
epoxy to prevent physical use of them.
It seems the problem you're having is you're still thinking from the
perspective of using systems intended for the general public (MacOS or
MS-Windows) where making things easy for stupid users is a primary
selling point and primary company concern due to support costs. Similar
is true for the virus licensed LINUX crap.
The first thing a real UNIX box will tell you to do is not simply
"no" but instead it's "fsck no, fsck off, go learn how things
work, and *maybe* then I might comply to your request."
It is a completely different mindset, "I'm sorry Dave, I can't do that."
> 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.
>
Has anyone here fumble fingered a command with sudo?
<everyone raises their hand>
You're given the gun and ammo, but where you decide to aim is your own
choice to make. If you don't bother to *think* about where you're
aiming, you'll eventually not like the results. Instead of becoming
desensitized to sudo, mentally make it a reminder to stop and think.
> > 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?
>
It's knowing all of the various pieces *and* how they interact *and*
all of the esoteric nuances and results of the interactions. In short,
it's a problem with a ton of variables, so the number of possible
combinations is staggering.
> > 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?
>
> 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.
>
As for which configuration is "easier" to understand, it does not
matter since "easier" depends on both what and how much you already
understand about how the system works. Yep, it's the same issue of
having tons of variables interacting in endless ways, as well as the
same issue of it being your choice how you want things done.
BTW, If you were implying lisp is static, you've got it backwards. The
common saying about the C language is, "C is good for writing systems
code." The equivalent saying for lisp is, "lisp is good for writing
lisp." It is much easier to write self-modifying code in lisp than in
any other language, so lisp is actually *very* dynamic, both in code
and data, and to add insult to injury, the separation between code and
data is not as clearly defined in lisp as it is in other languages.
The first time I touched a real UNIX system was over three decades
ago when I was kid in grade school, but I am *still* "new-to-unix" and
I am *still* learning... Have you ever "found" a new command or tool and
thought it was the one of the most useful things you've ever seen, but
you get to the end of reading the man page only to discover the command
been sitting there for decades waiting for you to to find it during all
your *years* of supposedly using the system? --You're not alone, and it
happens to everyone.
Yesterday I did not know what a "WIP" was, and sthen@ really did kindly
drop-kick me towards my new favorite tool, `pkg_add wtf`
--
J.C. Roberts
