Re: [Xenomai-help] Xenomai and mlockall

Re: [Xenomai-help] Xenomai and mlockall

[Fillod Stephane]

Philippe Gerum wrote:
> On Mon, 2007-06-25 at 15:00 +0200, Johan Borkhuis wrote: 
>> I am trying to run my Xenomai application as non-root. I disabled 
>> XENO_OPT_SECURITY_ACCESS to allow non-root users to run Xenomai 
>> applications. However, this causes my application to exit with the
error:
[...]
>> Is there a way to "tweak" the CAP_IPC_LOCK capability of the system
or 
>> the task so that I can run mlockall call, or is there a way to
disable 
>> this check on Xenomai?
>
>No way to disable it, since doing so would basically make your system
>dysfunctional by risking page faults while not running over a regular
>Linux context (i.e. Xenomai's primary domain).

I think Johan was not asking to disable the mlockall, but to allow some
non-root user to be able to do it. He found his solution anyway, which
is worth an entry in the FAQ.

Since it is going to be a FAQ for those people in embedded business,
some
tricks to allow non-root operation of mlockall, SCHED_FIFO, etc., would
be 
useful. For example, you may hack the commoncap in linux/security/, 
or a better solution would be to rely on realtime-lsm[1][2], thanks to 
the audio folks.

[1] http://sourceforge.net/projects/realtime-lsm/
[2] http://lwn.net/Articles/110346/


Best Regards,
-- 
Stephane

[Xenomai-core] Group-based RT caps (was: [Xenomai-help] Xenomai and mlockall)

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1281 bytes --]

Hi,

I'm moving this thread to xenomai-core as I have some implementation idea...

Fillod Stephane wrote:
> ...
> I think Johan was not asking to disable the mlockall, but to allow some.
> non-root user to be able to do it. He found his solution anyway, which
> is worth an entry in the FAQ.
> 
> Since it is going to be a FAQ for those people in embedded business,
> some
> tricks to allow non-root operation of mlockall, SCHED_FIFO, etc., would
> be 
> useful. For example, you may hack the commoncap in linux/security/, 
> or a better solution would be to rely on realtime-lsm[1][2], thanks to 
> the audio folks.
> 
> [1] http://sourceforge.net/projects/realtime-lsm/
> [2] http://lwn.net/Articles/110346/
> 

I think we could and should incorporate such a feature into the nucleus.

There is already code in xnshadow_map playing with cap_effective, but
that happens too late. Instead, we should establish a group-based access
control just like rt-lsm (the other knobs of that module are either
irrelevant for Xenomai (mlock=0) or broken security-wise (any=1)) and
raise the required caps for a process that belongs to the specified
group, likely when an Xenomai interface gets attached by that process.

Comments? Volunteer coders...?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] [Xenomai-help] Group-based RT caps

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

Jan Kiszka wrote:
> Hi,
> 
> I'm moving this thread to xenomai-core as I have some implementation idea...
> 
> Fillod Stephane wrote:
>> ...
>> I think Johan was not asking to disable the mlockall, but to allow some.
>> non-root user to be able to do it. He found his solution anyway, which
>> is worth an entry in the FAQ.
>>
>> Since it is going to be a FAQ for those people in embedded business,
>> some
>> tricks to allow non-root operation of mlockall, SCHED_FIFO, etc., would
>> be 
>> useful. For example, you may hack the commoncap in linux/security/, 
>> or a better solution would be to rely on realtime-lsm[1][2], thanks to 
>> the audio folks.
>>
>> [1] http://sourceforge.net/projects/realtime-lsm/
>> [2] http://lwn.net/Articles/110346/
>>
> 
> I think we could and should incorporate such a feature into the nucleus.
> 
> There is already code in xnshadow_map playing with cap_effective, but
> that happens too late. Instead, we should establish a group-based access
> control just like rt-lsm (the other knobs of that module are either
> irrelevant for Xenomai (mlock=0) or broken security-wise (any=1)) and
> raise the required caps for a process that belongs to the specified
> group, likely when an Xenomai interface gets attached by that process.

At this chance we should also remove CONFIG_XENO_OPT_SECURITY_ACCESS and
make the check mandatory. Due to the mlockall test, we effectively
demand raised privileges already. So there is no use in leaving other
Xenomai services open for non-privileged users.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] Group-based RT caps

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2664 bytes --]

Jan Kiszka wrote:
> Fillod Stephane wrote:
>> ...
>> I think Johan was not asking to disable the mlockall, but to allow some.
>> non-root user to be able to do it. He found his solution anyway, which
>> is worth an entry in the FAQ.
>>
>> Since it is going to be a FAQ for those people in embedded business,
>> some
>> tricks to allow non-root operation of mlockall, SCHED_FIFO, etc., would
>> be 
>> useful. For example, you may hack the commoncap in linux/security/, 
>> or a better solution would be to rely on realtime-lsm[1][2], thanks to 
>> the audio folks.
>>
>> [1] http://sourceforge.net/projects/realtime-lsm/
>> [2] http://lwn.net/Articles/110346/
>>
> 
> I think we could and should incorporate such a feature into the nucleus.
> 
> There is already code in xnshadow_map playing with cap_effective, but
> that happens too late. Instead, we should establish a group-based access
> control just like rt-lsm (the other knobs of that module are either
> irrelevant for Xenomai (mlock=0) or broken security-wise (any=1)) and
> raise the required caps for a process that belongs to the specified
> group, likely when an Xenomai interface gets attached by that process.
> 
> Comments? Volunteer coders...?

I couldn't resist, the approach looked too simple and appealing:

http://www.rts.uni-hannover.de/rtaddon/patches/xenomai/rt-caps-group.patch

Actually, it's even more advanced than realtime-lsm in so far as it also
checks for secondary group membership. You can use the nucleus module
parameter "xenomai_gid" to control the Xenomai group, also during
runtime using /sys.

Works nicely for me. I'm able to run testsuite programs under my user
account that now additionally belongs to the "xenomai" group. :)

One issue popped up and costed some nerves: linuxthreads-based
pthread_create() (non-NPTL glibc, uClibc) with SCHED_FIFO/RR attribute
fails already in userland because that library overeagerly checks for
root permissions. This is now worked around, but maybe not in the
cleanest way as it changes the initial thread scheduling order (more
problematic for the POSIX skin than for Native).


*BIG FAT WARNING*
Don't believe that this patch allows to run Xenomai applications in
whatever securely confined way! We grant CAP_SYS_RAWIO to all Xenomai
users, some Xenomai services can easily be corrupted/exploited from user
space (those based on shared heaps e.g.), and no one audits the core or
all the drivers for security. The advantage of having a separate Xenomai
group instead of just assigning root access directly is being able to
avoid _accidental_ changes, nothing more!

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] Group-based RT caps

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > Jan Kiszka wrote:
 > > Fillod Stephane wrote:
 > >> ...
 > >> I think Johan was not asking to disable the mlockall, but to allow some.
 > >> non-root user to be able to do it. He found his solution anyway, which
 > >> is worth an entry in the FAQ.
 > >>
 > >> Since it is going to be a FAQ for those people in embedded business,
 > >> some
 > >> tricks to allow non-root operation of mlockall, SCHED_FIFO, etc., would
 > >> be 
 > >> useful. For example, you may hack the commoncap in linux/security/, 
 > >> or a better solution would be to rely on realtime-lsm[1][2], thanks to 
 > >> the audio folks.
 > >>
 > >> [1] http://sourceforge.net/projects/realtime-lsm/
 > >> [2] http://lwn.net/Articles/110346/
 > >>
 > > 
 > > I think we could and should incorporate such a feature into the nucleus.
 > > 
 > > There is already code in xnshadow_map playing with cap_effective, but
 > > that happens too late. Instead, we should establish a group-based access
 > > control just like rt-lsm (the other knobs of that module are either
 > > irrelevant for Xenomai (mlock=0) or broken security-wise (any=1)) and
 > > raise the required caps for a process that belongs to the specified
 > > group, likely when an Xenomai interface gets attached by that process.
 > > 
 > > Comments? Volunteer coders...?
 > 
 > I couldn't resist, the approach looked too simple and appealing:
 > 
 > http://www.rts.uni-hannover.de/rtaddon/patches/xenomai/rt-caps-group.patch
 > 
 > Actually, it's even more advanced than realtime-lsm in so far as it also
 > checks for secondary group membership. You can use the nucleus module
 > parameter "xenomai_gid" to control the Xenomai group, also during
 > runtime using /sys.
 > 
 > Works nicely for me. I'm able to run testsuite programs under my user
 > account that now additionally belongs to the "xenomai" group. :)
 > 
 > One issue popped up and costed some nerves: linuxthreads-based
 > pthread_create() (non-NPTL glibc, uClibc) with SCHED_FIFO/RR attribute
 > fails already in userland because that library overeagerly checks for
 > root permissions. This is now worked around, but maybe not in the
 > cleanest way as it changes the initial thread scheduling order (more
 > problematic for the POSIX skin than for Native).

no problem with the posix skin: the scheduling order is enforced by the
use of a semaphore.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Group-based RT caps

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2725 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Jan Kiszka wrote:
>  > > Fillod Stephane wrote:
>  > >> ...
>  > >> I think Johan was not asking to disable the mlockall, but to allow some.
>  > >> non-root user to be able to do it. He found his solution anyway, which
>  > >> is worth an entry in the FAQ.
>  > >>
>  > >> Since it is going to be a FAQ for those people in embedded business,
>  > >> some
>  > >> tricks to allow non-root operation of mlockall, SCHED_FIFO, etc., would
>  > >> be 
>  > >> useful. For example, you may hack the commoncap in linux/security/, 
>  > >> or a better solution would be to rely on realtime-lsm[1][2], thanks to 
>  > >> the audio folks.
>  > >>
>  > >> [1] http://sourceforge.net/projects/realtime-lsm/
>  > >> [2] http://lwn.net/Articles/110346/
>  > >>
>  > > 
>  > > I think we could and should incorporate such a feature into the nucleus.
>  > > 
>  > > There is already code in xnshadow_map playing with cap_effective, but
>  > > that happens too late. Instead, we should establish a group-based access
>  > > control just like rt-lsm (the other knobs of that module are either
>  > > irrelevant for Xenomai (mlock=0) or broken security-wise (any=1)) and
>  > > raise the required caps for a process that belongs to the specified
>  > > group, likely when an Xenomai interface gets attached by that process.
>  > > 
>  > > Comments? Volunteer coders...?
>  > 
>  > I couldn't resist, the approach looked too simple and appealing:
>  > 
>  > http://www.rts.uni-hannover.de/rtaddon/patches/xenomai/rt-caps-group.patch
>  > 
>  > Actually, it's even more advanced than realtime-lsm in so far as it also
>  > checks for secondary group membership. You can use the nucleus module
>  > parameter "xenomai_gid" to control the Xenomai group, also during
>  > runtime using /sys.
>  > 
>  > Works nicely for me. I'm able to run testsuite programs under my user
>  > account that now additionally belongs to the "xenomai" group. :)
>  > 
>  > One issue popped up and costed some nerves: linuxthreads-based
>  > pthread_create() (non-NPTL glibc, uClibc) with SCHED_FIFO/RR attribute
>  > fails already in userland because that library overeagerly checks for
>  > root permissions. This is now worked around, but maybe not in the
>  > cleanest way as it changes the initial thread scheduling order (more
>  > problematic for the POSIX skin than for Native).
> 
> no problem with the posix skin: the scheduling order is enforced by the
> use of a semaphore.
> 

OK, that's good.

So if this patch might be worth merging, can we push the Linux scheduler
adjustments for all skins into the trampoline epilogue? Philippe?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] Group-based RT caps

[Johan Borkhuis]

Jan Kiszka wrote:
> I couldn't resist, the approach looked too simple and appealing:
> http://www.rts.uni-hannover.de/rtaddon/patches/xenomai/rt-caps-group.patch
>
> Actually, it's even more advanced than realtime-lsm in so far as it also
> checks for secondary group membership. You can use the nucleus module
> parameter "xenomai_gid" to control the Xenomai group, also during
> runtime using /sys.
>
> Works nicely for me. I'm able to run testsuite programs under my user
> account that now additionally belongs to the "xenomai" group. :)
>
> Jan
>   

I used the patch (and reversed my modification of MLOCK_LIMIT) and this 
works OK now, on a plain 2.3.1 version. Thanks!

One thing I would like to see is to have the xenomai_gid parameter as a 
kernel config parameter, next to the module parameter. The default can 
be -1, but I would like to have my configured xenomai-group as the 
default value, so I don't have to pass an extra parameter or modify 
/sys/module/xeno_nucleus/parameters/xenomai_gid.

Kind regards,
    Johan Borkhuis

Re: [Xenomai-core] Group-based RT caps

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

Johan Borkhuis wrote:
> Jan Kiszka wrote:
>> I couldn't resist, the approach looked too simple and appealing:
>> http://www.rts.uni-hannover.de/rtaddon/patches/xenomai/rt-caps-group.patch
>>
>>
>> Actually, it's even more advanced than realtime-lsm in so far as it also
>> checks for secondary group membership. You can use the nucleus module
>> parameter "xenomai_gid" to control the Xenomai group, also during
>> runtime using /sys.
>>
>> Works nicely for me. I'm able to run testsuite programs under my user
>> account that now additionally belongs to the "xenomai" group. :)
>>
>> Jan
>>   
> 
> I used the patch (and reversed my modification of MLOCK_LIMIT) and this
> works OK now, on a plain 2.3.1 version. Thanks!

Nice to hear.

> 
> One thing I would like to see is to have the xenomai_gid parameter as a
> kernel config parameter, next to the module parameter. The default can
> be -1, but I would like to have my configured xenomai-group as the
> default value, so I don't have to pass an extra parameter or modify
> /sys/module/xeno_nucleus/parameters/xenomai_gid.

Build the nucleus into the kernel, and you'll have it (with kernel 2.6
at least): "xeno_nucleus.xenomai_gid=<some-gid>"

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] Group-based RT caps

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

Jan Kiszka wrote:
> Johan Borkhuis wrote:
>> One thing I would like to see is to have the xenomai_gid parameter as a
>> kernel config parameter, next to the module parameter. The default can
>> be -1, but I would like to have my configured xenomai-group as the
>> default value, so I don't have to pass an extra parameter or modify
>> /sys/module/xeno_nucleus/parameters/xenomai_gid.
> 
> Build the nucleus into the kernel, and you'll have it (with kernel 2.6
> at least): "xeno_nucleus.xenomai_gid=<some-gid>"

Sorry, I likely misunderstood your request. You mean a build-time config
parameter? Hmm, that sounds a bit weird, given that you don't build your
/etc/passwd or /etc/group into the kernel either, do you?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] Group-based RT caps

[Johan Borkhuis]

Jan Kiszka wrote:
> Jan Kiszka wrote:
>   
>> Johan Borkhuis wrote:
>>     
>>> One thing I would like to see is to have the xenomai_gid parameter as a
>>> kernel config parameter, next to the module parameter. The default can
>>> be -1, but I would like to have my configured xenomai-group as the
>>> default value, so I don't have to pass an extra parameter or modify
>>> /sys/module/xeno_nucleus/parameters/xenomai_gid.
>>>       
>> Build the nucleus into the kernel, and you'll have it (with kernel 2.6
>> at least): "xeno_nucleus.xenomai_gid=<some-gid>"
>>     
>
> Sorry, I likely misunderstood your request. You mean a build-time config
> parameter? Hmm, that sounds a bit weird, given that you don't build your
> /etc/passwd or /etc/group into the kernel either, do you?
>
> Jan
>
>   
This was indeed what I meant. But I modified the default command line, 
which gives the same result.

I do have a standalone system where I can modify the group-file, so it 
is not a problem to have a fixed value for this option, as the 
xenomai-groups also has a fixed value.

Kind regards,
    Johan Borkhuis