Quoting Andrew Morgan ([EMAIL PROTECTED]):
> -----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.
It wouldn't use the new capabilities. The audit deamon, for instance,
would try to open an audit netlink socket, fail, report back that
the kernel does not have audit support, and then either exit or continue
logging to console or syslog, which doesn't require the new
capabilities.
> The app would have to be sure to check everything it does - even if it
No, the feature protected by the capability doesn't exist, and the app
already has to check for that :)
> 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.
I don't think so, because the if the capability does not exist, the
feature does not exist.
> >> - 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.
(I personally think 128-bit capabilities would be a disaster. Going
through capability.h to find the right capability to give to your
program will take hours.)
> 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.
I think that's very unlikely. I expect us to get to 33, maybe 34 or 35,
capabilities "real soon now", but take a long time to go beyond that.
> >> 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.
Well my *own* preference, as I've stated before, is to code the
capability version number into the xattr name, so that a file can carry
more than one capability version. Then always enforce versions
strictly. That way
1. If CAP_SYS_ADMIN is broken into multiple capabilities in v6,
a program affected by that can keep CAP_SYS_ADMIN in it's
security.capability.v5 xattr, and the subsets of it in it's
security.capability.v6 xattr.
2. If a new capability is introduced for a new feature - for
instance to control the ability to access objects/subjects
in another user namespace - a kernel without the capability
also lacks the feature, so programs using that feature should
detect that.
3. Fwd/backward compatibility is purely up to the admin or
distribution.
Anything else is either an unreasonable burden on distros trying to not
break the last kernel in their new release, or a potentially dangerous,
though I think containable, guess at future capabilities.
-serge
-
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
