On Sun, 23 Jul 2000, Khimenko Victor wrote:
>
> If you are talking about FILE in /dev - you can create it with mknod.
> If you are talking about DEVICE in kernel - you are disabling it with
> CAP_SYS_RAW and it'll make access to IDE commands not possible as well
> with proposed trivial 2-lines patch (HDIO_DRIVE_CMD IS raw I/O after
> all so why it was not protected by CAP_SYS_RAW in first place in
> mystery to me).
That, surely, is simply a bug? In which case, the patch someone posted
earlier to change the two capable() checks should solve it fine, even if
the author isn't a voter with a T-1...
> JS> We cannot switch *ANYTHING* off for root while retaining raw hardware
> JS> access.
>
> Yes. And that's why we need such two-lines patch, not some AI in kernel.
We need the extra pair of capable() calls, yes. We should also have sanity
checking in the kernel: usermode shouldn't be given this sort of power
directly, it should go through a proper, sanity-checked API. Just look at
the flak MS took for not sanity-checking all the WIN32K.SYS functions...
> JS> I'd use another capability (SYS_DESTROY_HARDWARE) which isn't enabled for
> JS> anything by default. Apart from that, it's OK.
>
> Sorry. You misunderstood things. HDIO_DRIVE_CMD can be used for other things
> (like PIO change or putting drive in sleep; heck - even firmware upgrades
> can be usefull sometimes). So it SHOULD NOT be disabled by default. Yes, it's
> dangerous, but so are A LOT OF other usefull things.
Potentially dangerous hardware-dependent things should be done by/via the
driver for that hardware, NOT by handing userspace a nuke and pointing it
at the target!
> >> > I prefer the latter - leaving those things lying around is just *begging*
> >> > for the next Linux crack story to go "some bastard got in with an old buffer
> >> > overflow exploit, and toasted my $10k server just by running a shell script".
> >> > I don't want to see that one...
> >>
> >> I don't as well but we have choice.
>
> JS> We NEED to block this function somehow.
>
> We can not.
Why not? All the uses you mention should be done through a proper kernel
API - NOT by userspace things on a "trust me, I'm being run by root"
basis.
> JS> Nope - /dev/kmem is gone.
>
> How so ? You are not using XFree86, right ? Then you can remove CAP_SYS_RAW
> from system and be happy.
So it has gone. That's my point.
> JS> So long as not having CAP_DESTROY_HARDWARE prevents this, and
> JS> CAP_DESTROY_HARDWARE isn't available to anything by default, that's OK.
>
> Sorry. We CAN NOT do this. Have you EVER looked on proposed patch or you are
> just lurking here ?
The proposed patch was deleted from zeus shortly after upload, so I can't
look at it. I'm not interested in what that specific patch actually does -
it's the *design* that matters, and THAT is what is being discussed.
> If not then go and read it then go back. It tries to distinguish "bad
> commands" and "good commands". Good commands are allowed while bad
> ones do not.
Yep - Linux would be fscking broken otherwise.
> The problem with this approach is simple: there ARE "bad" commands
> which can be used legetimely (for firmware upgrade, for example -
> that's why they are there in first place :-)
No, this sort of direct access is not legitimate. It should be done
through a proper sanity-checked API. The "give userspace a nuke and pray"
approach belongs in Redmond-born OSs, not Linux.
> and even worse: what's "bad" command with one IDE HDD vendor can be
> "good" one (and wanted not only in rare cases where you want to
> upgrade firmware) one for other IDE HDD vendor
This is exactly the sort of hardware-dependent detail which the kernel
driver should handle, NOT leave up to userspace.
> (think about things like Western Digital's activeX app to do low-level
> disk diagnostics).
Oh, yes - very useful. I really want a piece of WWW page to be able to do
low-level things to my hardware. If you think that's a genuine feature, go
back to Redmond and resume patching QDOS derivatives.
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:19 EST