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

[Lorenzo Hernández García-Hierro]

Hi,

Thanks to Magnus and Christian for poiting out bugs affecting the amd64
package and the postinst and postrm scripts. The installation was
overwriting /etc/modules due to a typo (echo ... > .. instead of echo ..
>> ...). I've fixed it an uploaded new packages. Christian, your
repository is longer needed, many thanks for the amd64 stuff! (please
re-build with the "new" sources). I haven't changed the revision number
though. Will do in next bump with the new features after I test them
over there.

Regarding...

$ 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.
 !!! PLEASE, REBOOT.

It's well known issue, and also note that the messages with '!!!' prefix
are sent by the postinst script of the package. It happens when you are
running with capabilities module loaded. For preventing processes to
lost the capabilities settings assigned to them, Martin proposed to add
a check. vSecurity needs a free slot within the LSM framework and thus,
will reject to load if there's no stack'able space. Capabilities module
uses one slot and SELinux another one, hence there's no room for a third
module. Although, the capabilities module has the 'disable' parameter
which allows us to implement the capabilities-related hooks in another
module and get a free slot. vSecurity will load then.

The packages drop a file in the /etc/modprobe.d/ directory containing
'options capability disable=1' and thus, will fix the issue but a reboot
is needed for clean setup.

There's no need if you don't care about lossing the capabilities
settings in the current processes, in such case go ahead:

 rmmod capability
 modprobe capability disable=1
 modprobe vsecurity

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.

In any case, those who are that paranoid should hesitate if using
computers is worth the whole picture.

I'm going to shut down this one now ;). Got to go for studying and
reading some stuff as usual...

I hope it's working well now for *everyone*. BTW, anyone has seen the
Launchpad team I've created? (ubuntu.hardened) Talked to Mark and
Launchpad is the way to go for next release. Those willing to contribute
should register an account and request to join the team.

Cheers,
-- 
Lorenzo Hernández García-Hierro <lorenzo at gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.ubuntu.com/archives/ubuntu-hardened/attachments/20051013/72670c74/attachment.pgp