Crispin Cowan wrote:
>David Wagner wrote:
>> Greg KH wrote:
>> >Ah, but Stephans program should first validate that the kernel is
>> >running SELinux by some other method than the syscall [...]
>>
>> Are there race conditions here? What if someone does a
>> 'rmmod selinux; insmod subdomain' between the time when
>> you check for the presence of SELinux and use the syscall?
>
>Isn't that isomorphic to the problem of "what if the bad guy got control
>of the machine before my module loaded?" To me, anyone who can do
>"rmmod" is either a trusted administrator, or has already broken
>security so hopelessly that it's not worth arguing about.
No, it's the difference between malicious attacks by untrusted
entities ("bad guy got control") and accidential failures by
trusted, well-intentioned entities (admin rmmod'ed, and some
app just happened to be a syscall at the same time).
I'm not worried about a malicious intruder doing the rmmod.
I'm worried that the admin is going to do the rmmod, for some
good reason, and some poor app is going to get inadvertently
hosed. It's a race condition, so it *probably* won't happen
to you very often, but then again, maybe this just makes it
all the more insidious.
>Similarly, I understand that RPM is not concurrent-safe, and you'll hose
>your system if you issue two parallel RPM commands as root. There are
>just some things that an admin ought not do :-)
I don't see the analogy. Here we would have to tell admins
that they can rmmod a LSM, but to install a new LSM they have
to reboot (or else kill all process that might have used an
extended syscall). The need to reboot every time you rmmod
a LSM seems pretty ugly.
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Aug 10 2001 - 18:33:28 PDT