Need Capabilities + Incapabilities
Posted Sep 21, 2013 8:21 UTC (Sat) by
ldo (subscriber, #40946)
Parent article:
BSD-style securelevel comes to Linux — again
Seems to me the answer to the issue of forward/backward compatibility when changing capability bits is to have two parts to the capability mask:
- A set of bits like the present one, where each set bit gives the process some ability. Existing bits should never be overloaded to add new abilities, as that could compromise the security of existing applications; instead, new abilities require new capability bits to enable them. Correspondingly, no new restrictions should be imposed on existing capability bits, to avoid breaking the functionality of existing applications; a particular bit, once defined, will always refer to the same set of abilities.
- A new set of incapability bits. These start out set to 1 for every process. As new security restrictions need to be added to the capability system, new bits can be assigned here that, when cleared, impose those restrictions. Leaving those bits set (the default) means the restrictions are not imposed on the process.
So the convention for applications is
- whitelist the capability bits, and
- blacklist the incapability bits.
That is, start out with the capability mask all 0, and the incapability mask all 1; set all the bits in the former for things that you know you need, and clear all the bits in the latter for things that you know you don’t need. Leave everything you don’t know about in its default state; 0 for capabilities, 1 for incapabilities. This will ensure maximum compatibility in the face of changes to the security model in the future.
Thoughts?
(
Log in to post comments)
