I've just set
CONFIG_SECURITY_FILE_CAPABILITIES=y

CONFIG_SECURITY_NETWORK_XFRM=y
to no avail.. I still get
20 Apr 15:04:20 ntpd[15694]: cap_set_proc() failed to drop root

privileges: Invalid argument
after rebuild & reboot. No massive deal, I'll just run ntpd as root for

now, but there's definitely something funny going on.
Cheers

David
--

--

Do you have a libcap that reflects the change from 32 capabilities

to 64? You'll be looking for libcap.so.2.06 or thereabouts.
Casey Schaufler

casey@schaufler-ca.com

--

Adding libcap-2.08 and recompiling ntpd has fixed the issue, and I'm now

running normally, thanks!
Was this userspace visible change planned in advance for 2.6.25 ? ... as

I guess a few other people with venerable old userspace components may

come across this issue.
Cheers

David

--

I don't understand why, though.  Looking at the ntpd code (ntp-4.2.4p4)

it just does a cap_set_proc(cap_from_text("X=epi"));  It should simply

be sending in the _LINUX_CAPABILITY_VERSION which shipped with libcap,

which should have been _V1, and the kernel should honor that so long as
It's been in the works a long time and we thought we'd done pretty

well with backward compatibility.  I really don't see why you had

that failure!
Do you know which version of libcap you had before?
thanks,

-serge

--

/lib/libcap.so.1 -> libcap.so.1.92
I guess that's 1.92 (should be the version shipped with SuSE 9.1).
Cheers

David
--

Ok, thanks, then it's definately not what I was thinking.
(Will wait to check out your strace)
thanks,

-serge

--

strace attached.
Cheers

David

This is odd.  libcap-1.x should be passing in 0x19980330.
Next, given the -EINVAL return value ntpd should be seeing a NULL result

from cap_get_proc() and exiting right there.
What version of ntpd is this?  (I must be looking at a wrong value, but

even so the fact that cap_get_proc()->capget() is using 0x20071026 for
thanks,

-serge

--

Oh dear .. more investigation... here's the source from libcap-1.92.

capget() is being called with null arguments, which I guess returns with

the latest version in ch.version ?
The switch then fails and the set gets called with version = 0 ??
Cheers

David
void _libcap_establish_api(void)

{

    struct __user_cap_header_struct ch;

    struct __user_cap_data_struct cs;
    if (_libcap_kernel_version) {

        _cap_debug("already identified kernal api 0x%.8x",

                   _libcap_kernel_version);

        return;

    }
    memset(&ch, 0, sizeof(ch));

    memset(&cs, 0, sizeof(cs));
    (void) capget(&ch, &cs);
    switch (ch.version) {
    case 0x19980330:

        _libcap_kernel_version = 0x19980330;

        _libcap_kernel_features = CAP_FEATURE_PROC;

        break;
    case 0x19990414:

        _libcap_kernel_version = 0x19990414;

        _libcap_kernel_features = CAP_FEATURE_PROC|CAP_FEATURE_FILE;

        break;
    default:

        _libcap_kernel_version = 0x00000000;

        _libcap_kernel_features = 0x00000000;

    }
    _cap_debug("version: %x, features: %x\n",

               _libcap_kernel_version, _libcap_kernel_features);
--

Interesting.  The version I was looking at (1.10) has nothing like this.
I don't know what shipped with recent RedHat and Fedora distros, but I

guess based on this we can in fact expect more failures from at least

SuSe distros.
We can't reasonably have newer kernels reply to a query with an older

libcap version, so I don't know what to do here.  Andrew, do you have

any ideas?
thanks,

-serge

--

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Short version:
As you have found, libcap2 does address your problem. I suspect that

libcap-1.97 here:
http://www.kernel.org/pub/linux/libs/security/linux-privs/libcap1/
will also prove successful. Please try it and report...
Thanks
Andrew
Long, and "almost funny" version:
A reason this fails on SUSE, is that SUSE appears to be shipping an

experimental version of libcap 1.92 (+ patches). That is I downloaded

the src.rpm from here:
http://download.opensuse.org/distribution/SL-10.1/inst-source/suse/src/
Did the "rpm2cpoi/cpio --extract" chicken dance and, much to my

surprise, discovered the package is based on an experimental version of

libcap that I had made (on a speculative libcap2 branch on sourceforge)

to work with some ancient (and experimental) filesystem capability

support (patches etc., captured here):
http://www.kernel.org/pub/linux/libs/security/linux-privs/old/kernel-2.2...
This kernel patch was never integrated into the kernel, and Serge did

not go even remotely close to it for the final implementation of

filesystem capabilities in the kernel. Needless to say that this (old)

'experimental' libcap fails to work with the new 'released' kernel

support is not at all surprising! :-(
[FWIW The old experimental support extended the capset/capget system

call interface to manipulate filesystem capabilities, where Serge's

patch does this directly via extended attribute system calls. These two

access methods appear to be clashing quite horribly - but failing "safe".]
I believe code based on released version: libcap-1.10 and/or libcap-1.97

which you can download here:
http://www.kernel.org/pub/linux/libs/security/linux-privs/libcap1/
should work. You might like to try 1.97 as a replacement for the SUSE

version and report any issues (the SUSE guys may need to think about a

migration path).
serge@hallyn.com wrote:

| Quoting David (david@unsolicited.net):

|> serge@hallyn.com wrote:

|>&gt...
[ message continues ]

I daresay it will, but libcap v2 sorts my problems out so I'm happy.

It's unfortunate that old versions of SuSE shipped with buggy libcap

as the breakage will be blamed on the kernel upgrade. One of those

things I guess.
David
--

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
serge@hallyn.com wrote:

| Quoting David (david@unsolicited.net):

|> Casey Schaufler wrote:

|>> Do you have a libcap that reflects the change from 32 capabilities

|>> to 64? You'll be looking for libcap.so.2.06 or thereabouts.

|>>

|> Adding libcap-2.08 and recompiling ntpd has fixed the issue, and I'm now

|> running normally, thanks!

|

| I don't understand why, though.  Looking at the ntpd code (ntp-4.2.4p4)

| it just does a cap_set_proc(cap_from_text("X=epi"));  It should simply

| be sending in the _LINUX_CAPABILITY_VERSION which shipped with libcap,

| which should have been _V1, and the kernel should honor that so long as

| you didn't try to send in caps > 31, which ntpd wasn't.

|

|> Was this userspace visible change planned in advance for 2.6.25 ? ...

as I

|> guess a few other people with venerable old userspace components may

come

|> across this issue.

|>

|> Cheers

|> David

|

| It's been in the works a long time and we thought we'd done pretty

| well with backward compatibility.  I really don't see why you had

| that failure!
I'm confused (and somewhat concerned) about this too. 32-bit capability

apps should act fine. The only thing you might notice is a strange

comment about it in /var/log/messages.
David, can you run strace on the failing program (configuration)?
[I'll see if I can read the complete thread on one of the archives and

see if anything else sticks out.]
Thanks
Andrew
|

| Do you know which version of libcap you had before?

|

| thanks,

| -serge

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.7 (Darwin)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIC+NP+bHCR3gb8jsRAjunAKDXe/fDfwIJWi6wgtpdxZefbRq5SACffb1+

pQNi1C/8PPGWYpUXFxizUuI=

=LHl0

-----END PGP SIGNATURE-----

--

I'll not be able to do that 'till this evening (GMT+1), but will post

an strace then.
Cheers

David
--

FWIW I ran into this problem too with systemtap. It was a quite

nasty surprise and took some time to track down.
I also don't remember seeing a thread about this on l-k.  Where was this

major binary breakage discussed?
-Andi
--

lkml and lsm.
Casey Schaufler

casey@schaufler-ca.com

--

> lkml and lsm.
Can you be more exact please? I skimmed the last 1k messages in the

lsm archive and there was nothing standing out.
-Andi

--