[ubuntu-hardened] Re: Fixed some bugs in the postinst and postrm scripts of vSecurity packages, merged amd64 changes

Magnus Therning magnus at therning.org
Fri Oct 14 04:44:46 CDT 2005

On Thu, Oct 13, 2005 at 06:48:12PM +0200, Lorenzo Hernández García-Hierro wrote:
>$ sudo apt-get install vsecurity
> ...
> Setting up vsecurity-686 (0.3-0ubuntu1) ...
> FATAL: Error inserting vsecurity (/lib/modules/2.6.12-9-686/kernel/security/vsecurity.ko): Invalid argument
> !!! Capabilities module blocks vSecurity. For keeping capabilities set in current processes, a reboot is needed.
[.. explanation of fatal error inserting vsecurity ..]

Thanks for the clarification. It looks much worse than it is then :-)

Is there any documentation at all for vsecurity?
In the `documentation` dir there's only one file, on BSD jails. I'm not
sure that doc is worth very much since it seems one needs to know what a
BSD jail is in order to understand the explanation of a BSD jail in
there (I am not that familiar with the term). The examples for setting
up a jail is also a little confusing, they refer to executables I don't
have on my system, not even after installing vsecurity.

I'd also like to see some more details on the other parts of the module.

>BTW, I'm thinking about adding a by-parameter-configured feature
>implementing "kernel sealing". Let's clarify that "sealing" concept.
>I'm sure most of us know that a kernel open for LKMs is a kernel
>providing interfaces for a wide range of malicious or dangerous
>operations (ie.  runtime patching, rootkit installation, etc). The
>problem is that we can't cut certain capabilities without affecting
>programs execution flow. CapOver changes (to be merged) will deploy a
>fine-grained control (using a simplistic policy language) over which
>capabilities are granted to each binary, but this may sound still weak
>to security junkies and other people (like myself a few times...),
>hence the need of an extra option. We could try to seal the kernel
>preventing any further modules to be loaded until reboot (think that,
>when you're root in the machine and there's no MAC engine running, but
>only DAC, root can virtually do anything). Also, we could try to limit
>CAP_SYS_RAWIO or even removing it from the
>capabilities-that-can-be-granted ring (return -EPERM when requested
>within the capable() hook). This is not a difficult thing to get done
>but I want to hear your opinion about it, before I work out something
>by myself and commit it to CVS.

I've always been leaning somewhat towards saying that this isn't
necessary. Plugging the loadable-kernel-module hole (be it a security
module or a regular module) is done easiest by simply not compiling in
support for loading kernel modules. :-)

I could see a use for your "sealing" in test systems---adding hardware
requires a reboot rather than a kernel compilation.

Another use, that I might have myself is for the times when I enter my
laptop into a network I don't really trust. Just as an extra precaution
I'd "seal" my kernel before hooking it into the network. I think I could
live with having to reboot to "unseal" it again.


Magnus Therning                    (OpenPGP: 0xAB4DFBA4)
magnus at therning.org

Software is not manufactured, it is something you write and publish.
Keep Europe free from software patents, we do not want censorship
by patent law on written works.

rogrammers and programs alike need die gracefully upon failure, and
exit with no system disruption.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.ubuntu.com/archives/ubuntu-hardened/attachments/20051014/f9f298aa/attachment.pgp

More information about the ubuntu-hardened mailing list