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
http://vserver.13thfloor.at/Stuff/delta-vxcapable-fix01a.diff
the vs2.0.2-rc18 and vs2.1.1-rc18 releases for 2.6.16.11
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
HTH,
Herbert
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Fri Apr 28 03:25:26 2006