Linux capabilities shouldn't be lost during setuid to non-root from root or to another non-root uid from a non-root uid.

Linux capabilities shouldn't be lost during setuid to non-root from root or to another non-root uid from a non-root uid.

[crocket]

Linux capabilities exist to split root previlege to dozens of subsets
of previleges.
But after setuid, all linux capabilities gained from a file are gone for good.
This becomes a problem with OpenVPN.

If I use --mlock option and --user option in OpenVPN, OpenVPN locks
memory with mlockall as root and drops to a non-root user specififed
by --user option.
After dropping to a non-root user, the process loses CAP_IPC_LOCK
capability gained from OpenVPN executable which I personally set.
Because the process doesn't have CAP_IPC_LOCK capability and its UID
isn't 0, further attempts to allocate memory more than "ulimit -l" to
openvpn crash OpenVPN.
This defeats the purpose of linux capabilities.
Linux capabilities exist to give a subset or subsets of previleges to
processes whose UID is greater than 0(root).

Can somebody provide or merge a patch that prevents linux from losing
capabilities after setuid?

Re: Linux capabilities shouldn't be lost during setuid to non-root from root or to another non-root uid from a non-root uid.

[Serge E. Hallyn]

You need

	prctl(PR_SET_KEEPCAPS, 1);

man prctl for details.  In particular, see the following example:

#include <stdio.h>
#include <sys/prctl.h>
#include <sys/capability.h>

int main()
{
	cap_t c;
	c = cap_get_proc();
	printf("uid %d, current caps: %s\n", getuid(), cap_to_text(c, NULL));
	cap_free(c);
	prctl(PR_SET_KEEPCAPS, 1);
	setuid(1001, 1001, 1001);
	c = cap_get_proc();
	printf("uid %d, current caps: %s\n", getuid(), cap_to_text(c, NULL));
	cap_free(c);
}

You can either run that as root, or you can do

	sudo setcap cap_setuid,cap_setgid,cap_sys_admin=eip captest

and then run it as non-root.

HTH,
-serge

Re: Linux capabilities shouldn't be lost during setuid to non-root from root or to another non-root uid from a non-root uid.

[crocket]

prctl(PR_SET_KEEPCAPS, 1) didn't work since, during setuid to
non-root, effective bit was lost.

Please refer to "man prctl".

I don't know what would happen when I run OpenVPN as non-root with
cap_setuid, cap_setgid, cap_sys_admin.
I guess OpenVPN woull fail to generate tun0 interface if it's run as root.
However, I need to test it to be sure.

On Mon, Apr 18, 2011 at 3:07 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> You need
>
>        prctl(PR_SET_KEEPCAPS, 1);
>
> man prctl for details.  In particular, see the following example:
>
> #include <stdio.h>
> #include <sys/prctl.h>
> #include <sys/capability.h>
>
> int main()
> {
>        cap_t c;
>        c = cap_get_proc();
>        printf("uid %d, current caps: %s\n", getuid(), cap_to_text(c, NULL));
>        cap_free(c);
>        prctl(PR_SET_KEEPCAPS, 1);
>        setuid(1001, 1001, 1001);
>        c = cap_get_proc();
>        printf("uid %d, current caps: %s\n", getuid(), cap_to_text(c, NULL));
>        cap_free(c);
> }
>
> You can either run that as root, or you can do
>
>        sudo setcap cap_setuid,cap_setgid,cap_sys_admin=eip captest
>
> and then run it as non-root.
>
> HTH,
> -serge
>

Re: Linux capabilities shouldn't be lost during setuid to non-root from root or to another non-root uid from a non-root uid.

[Serge E. Hallyn]

Quoting crocket (crockabiscuit@gmail.com):
> prctl(PR_SET_KEEPCAPS, 1) didn't work since, during setuid to
> non-root, effective bit was lost.

It's in pP so you can move it back to pE.

-serge

Re: Linux capabilities shouldn't be lost during setuid to non-root from root or to another non-root uid from a non-root uid.

[crocket]

I don't like the fact that an application should be linux-specific to
keep capabilities after setuid.
If users added capabilities to a file, they would know what they were
doing, and they would want applications to keep capabilities even
after setuid.

If linux capabilities were kept after setuid by default, system
administration and programming would become easier.

Re: Linux capabilities shouldn't be lost during setuid to non-root from root or to another non-root uid from a non-root uid.

[Serge E. Hallyn]

Quoting crocket (crockabiscuit@gmail.com):
> I don't like the fact that an application should be linux-specific to
> keep capabilities after setuid.
> If users added capabilities to a file, they would know what they were
> doing, and they would want applications to keep capabilities even
> after setuid.

Alternatively, you could call the program using a wrapper which first
sets the SECBIT_NO_SETUID_FIXUP securebit, after which setuid would
not trigger any capability changes.

-serge

Re: Linux capabilities shouldn't be lost during setuid to non-root from root or to another non-root uid from a non-root uid.

[crocket]

I have several questions.

1) How do I set SECBIT_NO_SETUID_FIXUP?

2) Is there any reason to unset SECBIT_NO_SETUID_FIXUP by default?

On Mon, Apr 18, 2011 at 5:28 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> Quoting crocket (crockabiscuit@gmail.com):
>> I don't like the fact that an application should be linux-specific to
>> keep capabilities after setuid.
>> If users added capabilities to a file, they would know what they were
>> doing, and they would want applications to keep capabilities even
>> after setuid.
>
> Alternatively, you could call the program using a wrapper which first
> sets the SECBIT_NO_SETUID_FIXUP securebit, after which setuid would
> not trigger any capability changes.
>
> -serge
>

Re: Linux capabilities shouldn't be lost during setuid to non-root from root or to another non-root uid from a non-root uid.

[Serge E. Hallyn]

Quoting crocket (crockabiscuit@gmail.com):
> I have several questions.
> 
> 1) How do I set SECBIT_NO_SETUID_FIXUP?

prctl(PR_SET_SECUREBITS, SECBIT_NO_SETUID_FIXUP | SECBIT_NO_SETUID_FIXUP_LOCKED)

see capabilities(7) for details.

> 2) Is there any reason to unset SECBIT_NO_SETUID_FIXUP by default?

Yes, because it's what userspace expects.  If you prefer to run in
a full POSIX capabilities environment with unprivileged root, you
can have init set SECBIT_NO_SETUID_FIXUP and SECBIT_NOROOT and
tune userspace to do the right thing, but it's not trivial.

-serge

Re: Linux capabilities shouldn't be lost during setuid to non-root from root or to another non-root uid from a non-root uid.

[crocket]

Is there an existing utility that sets SECBIT_NO_SETUID_FIXUP?
Or is there a way to set it without writing a C wrapper program?

On Tue, Apr 19, 2011 at 7:02 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> Quoting crocket (crockabiscuit@gmail.com):
>> I have several questions.
>>
>> 1) How do I set SECBIT_NO_SETUID_FIXUP?
>
> prctl(PR_SET_SECUREBITS, SECBIT_NO_SETUID_FIXUP | SECBIT_NO_SETUID_FIXUP_LOCKED)
>
> see capabilities(7) for details.
>
>> 2) Is there any reason to unset SECBIT_NO_SETUID_FIXUP by default?
>
> Yes, because it's what userspace expects.  If you prefer to run in
> a full POSIX capabilities environment with unprivileged root, you
> can have init set SECBIT_NO_SETUID_FIXUP and SECBIT_NOROOT and
> tune userspace to do the right thing, but it's not trivial.
>
> -serge
>

Re: Linux capabilities shouldn't be lost during setuid to non-root from root or to another non-root uid from a non-root uid.

[Serge E. Hallyn]

Quoting crocket (crockabiscuit@gmail.com):
> Is there an existing utility that sets SECBIT_NO_SETUID_FIXUP?
> Or is there a way to set it without writing a C wrapper program?

You can use capsh (with --secbits=), which ships with libcap2.

-serge

Re: Linux capabilities shouldn't be lost during setuid to non-root from root or to another non-root uid from a non-root uid.

[crocket]

Thanks for the precious information.

I think capsh should be introduced somewhere in some manuals.

On Tue, Apr 19, 2011 at 10:14 AM, crocket <crockabiscuit@gmail.com> wrote:
> Is there an existing utility that sets SECBIT_NO_SETUID_FIXUP?
> Or is there a way to set it without writing a C wrapper program?
>
> On Tue, Apr 19, 2011 at 7:02 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
>> Quoting crocket (crockabiscuit@gmail.com):
>>> I have several questions.
>>>
>>> 1) How do I set SECBIT_NO_SETUID_FIXUP?
>>
>> prctl(PR_SET_SECUREBITS, SECBIT_NO_SETUID_FIXUP | SECBIT_NO_SETUID_FIXUP_LOCKED)
>>
>> see capabilities(7) for details.
>>
>>> 2) Is there any reason to unset SECBIT_NO_SETUID_FIXUP by default?
>>
>> Yes, because it's what userspace expects.  If you prefer to run in
>> a full POSIX capabilities environment with unprivileged root, you
>> can have init set SECBIT_NO_SETUID_FIXUP and SECBIT_NOROOT and
>> tune userspace to do the right thing, but it's not trivial.
>>
>> -serge
>>
>

Re: Linux capabilities shouldn't be lost during setuid to non-root from root or to another non-root uid from a non-root uid.

[Serge E. Hallyn]

Quoting crocket (crockabiscuit@gmail.com):
> Thanks for the precious information.
> 
> I think capsh should be introduced somewhere in some manuals.

Would mentioning capsh in capabilities(7) be a good idea?

> On Tue, Apr 19, 2011 at 10:14 AM, crocket <crockabiscuit@gmail.com> wrote:
> > Is there an existing utility that sets SECBIT_NO_SETUID_FIXUP?
> > Or is there a way to set it without writing a C wrapper program?
> >
> > On Tue, Apr 19, 2011 at 7:02 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> >> Quoting crocket (crockabiscuit@gmail.com):
> >>> I have several questions.
> >>>
> >>> 1) How do I set SECBIT_NO_SETUID_FIXUP?
> >>
> >> prctl(PR_SET_SECUREBITS, SECBIT_NO_SETUID_FIXUP | SECBIT_NO_SETUID_FIXUP_LOCKED)
> >>
> >> see capabilities(7) for details.
> >>
> >>> 2) Is there any reason to unset SECBIT_NO_SETUID_FIXUP by default?
> >>
> >> Yes, because it's what userspace expects.  If you prefer to run in
> >> a full POSIX capabilities environment with unprivileged root, you
> >> can have init set SECBIT_NO_SETUID_FIXUP and SECBIT_NOROOT and
> >> tune userspace to do the right thing, but it's not trivial.
> >>
> >> -serge
> >>
> >

Re: Linux capabilities shouldn't be lost during setuid to non-root from root or to another non-root uid from a non-root uid.

[crocket]

On Tue, Apr 19, 2011 at 11:35 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> Quoting crocket (crockabiscuit@gmail.com):
>> Thanks for the precious information.
>>
>> I think capsh should be introduced somewhere in some manuals.


     Yes I think mentioning capsh in capabilities(7) would be a good idea.


>
> Would mentioning capsh in capabilities(7) be a good idea?
>
>> On Tue, Apr 19, 2011 at 10:14 AM, crocket <crockabiscuit@gmail.com> wrote:
>> > Is there an existing utility that sets SECBIT_NO_SETUID_FIXUP?
>> > Or is there a way to set it without writing a C wrapper program?
>> >
>> > On Tue, Apr 19, 2011 at 7:02 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
>> >> Quoting crocket (crockabiscuit@gmail.com):
>> >>> I have several questions.
>> >>>
>> >>> 1) How do I set SECBIT_NO_SETUID_FIXUP?
>> >>
>> >> prctl(PR_SET_SECUREBITS, SECBIT_NO_SETUID_FIXUP | SECBIT_NO_SETUID_FIXUP_LOCKED)
>> >>
>> >> see capabilities(7) for details.
>> >>
>> >>> 2) Is there any reason to unset SECBIT_NO_SETUID_FIXUP by default?
>> >>
>> >> Yes, because it's what userspace expects.  If you prefer to run in
>> >> a full POSIX capabilities environment with unprivileged root, you
>> >> can have init set SECBIT_NO_SETUID_FIXUP and SECBIT_NOROOT and
>> >> tune userspace to do the right thing, but it's not trivial.
>> >>
>> >> -serge
>> >>
>> >
>