-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Serge E. Hallyn wrote: >> So far as I can see there are two types of issue: >> >> - a new capability comes along - it is needed to run an app > > As an example, CAP_AUDIT_WRITE and CAP_AUDIT_CONTROL were > added along with new features they control. Allowing the > audit daemon to run gives it a chance to tell the admin that > the kernel is too old. Refusing execve probably suggests > the same thing, though it may be more confusing. But in > any case it seems likely to me that a new capability will > protect a new feature, which will not be present, so the > lack of the capability will be no more dangerous than the > lack of the feature.
Can you walk me through how a legacy (capability unaware) application can use these new capabilities? To me it seems that the admin can't set the app: ep=cap_audit_write,cap_audit_control when running under kernel Gen2 and get sane behavior when the app is run from an old kernel of Gen1. The app would have to be sure to check everything it does - even if it knew things should work because it expects to be running setuid-0 with full root privilege. This is the class of requirement that sendmail was expected to observe, and where the 'infamous' sendmail-capability bug hid. >> - an old capability (eg. CAP_SYS_ADMIN) is split into two > > This particular case would be cause to bump the version number, since > the meaning of existing cap bits has changed. If the version # is > bumped to 3, the patch I sent will still return -EINVAL. Let's think about this beyond one iteration. We've no reason not to suppose we'll have V1 (32-bits), V2 (64-bits) and V3 (128-bits)... etc. What we expect is that a system configured to expect a V2 kernel to be running will have 64-bit filesystem capabilities in it. If the system is booted with a V1 kernel, then the capabilities will be partially interpreted and the app will be run with that partial interpretation by the V1 kernel. However, you observe that if things get complicated - if the magic number for the capabilities changes - then the capabilities will deny access... Now, the magic for V3 (128-bit capabilities) will clearly have a new magic number - unanticipated today, so V3 capabilities will yield - -EINVAL on a V1 kernel. OK. So what happens if we decide (in the near future) that 64-bit capabilities are insufficient, and jump straight from 32-bit to 128-bits? The code you are contemplating now which reserves a magic number for 64-bits and we can't use that magic number; we've created a legacy we can't use. >> In the old kernel how could the 'desired behavior' for the new file >> attribute be guessed correctly? > > It can't. > > Whoever is introducing the new capability will need to decide > whether it warrants bumping the version #. Isn't this likely to be the common case? I can imagine a situation where the V2 (or V3 etc.) kernel would read a V1 file capability set and want to figure out what it is equivalent to in terms of V2 etc., capabilities. But this is backward compatibility, and much more tractable than forward compatibility. Cheers Andrew -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFGt/6eQheEq9QabfIRAnGVAJ4mRQ/yAWu8966glPibNZKIEIWR+wCeIgZQ 5hd/JwDz97ElQGOWgvFobUg= =wwI5 -----END PGP SIGNATURE----- - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
