[Vserver] [SECURITY] ccaps not limited to root inside a guest

From: Herbert Poetzl <herbert_at_13thfloor.at>
Date: Fri 28 Apr 2006 - 03:25:04 BST
Message-ID: <20060428022503.GA6756@MAIL.13thfloor.at>

Hi Community!

Jan Rekorajski reported an issue which basically went
unnoticed till now, here are the details:

the various context capabilities (ccaps) add certain
'rights' to a guest, which allow to modify guest
specific things which are otherwise forbidden like:

   SET_UTSNAME ..... set guest uts information
   SET_RLIMIT ....... set guest side resource limits
   SYSLOG ........... read a virtualized syslog
   SECURE_MOUNT ..... do 'secure' mounts inside
   SECURE_REMOUNT ... same for remounts
   BINARY_MOUNT ..... and network mounts
   QUOTA_CTL ........ allow quota ioctls
   RAW_ICMP ......... allow to use ping inside

accidentially those context specific overrides are not
limited to the guest-root but also apply to other users
inside the guest, so that, for example, some non-root
guest user can change the hostname of the guest.

basically all 2.6 kernels are affected, but of course
only if they contain the context capability.

   SET_UTSNAME 0.09.10 or later
   SET_RLIMIT 0.09.12 or later
   SECURE_MOUNT vs1.9.1 or later
   SYSLOG vs2.0-rc1 or later
   QUOTA_CTL vs2.0-rc2 or later

I would suggest the following procedures to secure
production systems:

 - first check if any of your guests has such ccaps
   set (except for the RAW_ICMP, which can be ignored)

   # grep CCaps /proc/virtual/[0-9]*/status

   if you see 0000000000000100, then no critical ccap
   is enabled and you can forget about it.

   unfortunately the default seems to be 101, which
   means that the issue applies for the utsname

 - if you found guests where this applies, you can
   secure them at runtime with the following command:

   # vattribute --set --xid <xid> --bcap -1 --ccap ~-1 --ccap ^8
   where <xid> is the context id of your guest
   (be careful, a wrong bcap can mess up your guest)

 - the next step would be to remove those ccaps from
   the config tree (so that they do not come back on
   guest restart)

 - alternatively the following kernel patch fixes the
   issue for stable and devel kernels for 2.6.16 and
   later, but might need a little massaging for older
   (2.6.14/2.6.15) kernels


the vs2.0.2-rc18 and vs2.1.1-rc18 releases for
do already include proper fixes for this issue, so an
upgrade should get rid of this misbehaviour.

note: this is a security issue on the guest side, not
on the host side, so it does not give any unwanted
permissions to the guest, and could be simply ignored
if you do not care about guest root vs. guest user


Vserver mailing list
Received on Fri Apr 28 03:25:26 2006

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Fri 28 Apr 2006 - 03:25:32 BST by hypermail 2.1.8