Quoting Kyle Moffett ([email protected]):
> On Jun 25, 2007, at 16:37:58, Andreas Gruenbacher wrote:
> >On Monday 25 June 2007 06:33, James Morris wrote:
> >>Convert LSM into a static interface, as the ability to unload a
> >>security module is not required by in-tree users and potentially
> >>complicates the overall security architecture.
> >
> >It's useful for some LSMs to be modular, and LSMs which are y/n
> >options won't have any security architecture issues with unloading
> >at all. The mere fact that SELinux cannot be built as a module is a
> >rather weak argument for disabling LSM modules as a whole, so
> >please don't.
>
> Here are a few questions for you:
>
> 1) What do you expect to happen to all the megs of security data
> when you "rmmod selinux"?
Read the sentence right above yours again.
Noone is saying we should be able to rmmod selinux.
> Do you maintain a massive linked list of
> security data (with all the locking and performance problems) so that
> you can iterate over it calling kfree()? What synchronization
> primitive do we have right now which could safely stop all CPUs
> outside of security calls while we NULL out and free security data
> and disable security operations? Don't say "software suspend" and
> "process freezer", since those have whole order-of-magnitude-
> complexity problems of their own (and don't always work right either).
>
> 2) When you "modprobe my_custom_security_module", how exactly do
> you expect that all the processes, files, shared memory segments,
> file descriptors, sockets, SYSV mutexes, packets, etc will get
> appropriate security pointers?>
Those don't all need labels for capabilities, for instance. This
question is as wrong as the last one.
> This isn't even solvable the same way
> the "rmmod" problem is, since most of that isn't even accessible
> without iterating over the ENTIRE dcache, icache, every process,
> every process' file-descriptors, every socket, every unix socket,
> every anonymous socket, every SYSV shm object, every currently-in-
> process packet.
>
> 3) This sounds suspiciously like "The mere fact that the
> Linux-2.6-VM cannot be built as a module is a rather weak argument
> for disabling VFS modules as a whole". We don't do "pluggable
No, your argument sounds like "my fs can't be a module so neither should
any."
> fundamental infrastructure" in Linux. If it's fundamental
> infrastructure then you eliminate as many differences as possible and
> leave the rest to CONFIG options (or delete it entirely).
>
>
> So... Do you have a proposal for solving those rather fundamental
> design gotchas? If so, I'm sure everybody here would love to see
> your patch; though maybe not if it's a 32MB patch-zilla-of-doom (AKPM
> beware, the merge-conflict-from-hell is on its way). On the other
> hand, if you accept that these problems basically can't be solved and
> we make things static and rip out a bunch of code, we can probably
> improve our performance under larger security models (like SELinux/
> AppArmor/TOMOYO/MagicSecurityFlavorOfTheWeek(TM)) by a percent or two.
>
> Cheers,
> Kyle Moffett
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-security-module" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
