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?
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
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 <[email protected]> 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
>
Quoting crocket ([email protected]):
> 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
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.
Quoting crocket ([email protected]):
> 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
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 <[email protected]> wrote:
> Quoting crocket ([email protected]):
>> 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
>
Quoting crocket ([email protected]):
> 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
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 <[email protected]> wrote:
> Quoting crocket ([email protected]):
>> 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
>
Quoting crocket ([email protected]):
> 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
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 <[email protected]> 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 <[email protected]> wrote:
>> Quoting crocket ([email protected]):
>>> 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
>>
>
Quoting crocket ([email protected]):
> 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 <[email protected]> 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 <[email protected]> wrote:
> >> Quoting crocket ([email protected]):
> >>> 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
> >>
> >
On Tue, Apr 19, 2011 at 11:35 PM, Serge E. Hallyn <[email protected]> wrote:
> Quoting crocket ([email protected]):
>> 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 <[email protected]> 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 <[email protected]> wrote:
>> >> Quoting crocket ([email protected]):
>> >>> 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
>> >>
>> >
>