Editing
Msg13167.html
From Linix VServer
Jump to navigation
Jump to search
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
----- [<nowiki/>[[msg13166.html|Date Prev]]][<nowiki/>[[msg13168.html|Date Next]]][<nowiki/>[[msg13165.html|Thread Prev]]][<nowiki/>[[msg13172.html|Thread Next]]][<nowiki/>[[index.html#13167|Date Index]]][<nowiki/>[[threads.html#13167|Thread Index]]] <span id="vserver-security-ccaps-not-limited-to-root-inside-a-guest"></span> = [Vserver] [SECURITY] ccaps not limited to root inside a guest = ----- * '''From:''' Herbert Poetzl * '''Date:''' Fri, 28 Apr 2006 04:25:07 +0200 (CEST) ----- <pre> 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 </pre> ----- * '''Follow-Ups''': ** '''[[msg13172.html|Re: [Vserver] [SECURITY] ccaps not limited to root inside a guest]]''' *** ''From:'' Benedikt BΓhm * Prev by Date: '''[[msg13166.html|Re: [Vserver] vserver features]]''' * Next by Date: '''[[msg13168.html|Re: [Vserver] Timeout and SIGKILL error upon guest stop]]''' * Previous by thread: '''[[msg13165.html|[Vserver] Timeout and SIGKILL error upon guest stop]]''' * Next by thread: '''[[msg13172.html|Re: [Vserver] [SECURITY] ccaps not limited to root inside a guest]]''' * Index(es): ** [[index.html#13167|'''Date''']] ** [[threads.html#13167|'''Thread''']]
Summary:
Please note that all contributions to Linix VServer may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Linix VServer:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Navigation menu
Page actions
Page
Discussion
Read
Edit
History
Page actions
Page
Discussion
More
Tools
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
About
Overview
Paper
News
Developers
Donations
Search
Getting Started
Downloads
FAQs
Documentation
Support
Participate
How to participate
Report a Bug
Communicate
Teams/Projects
Hall of Fame
Resources
Archives
Recent Wiki Changes
Pastebin
Related Projects
VServer Hosting
Happy VServer Users
Tools
What links here
Related changes
Special pages
Page information