[Xenomai-help] Xenomai and capabilities

[Xenomai-help] Xenomai and capabilities

[Anders Blomdell]

We are planning to extend our use of xenomai to a wider audience at our
department, and therefore I would like to know which is the better way to let
users run xenomai programs with a minimum of system privileges, the
possibilities I can see are:

1. Let the user run anything as root; simple but obviously a security nightmare.
2. Write a suid program that let's its children inherit the right capabilities
and then does a seteuid and does an execve; unfortunately this implies that the
program that is execve'd has the right capabilties set [which has to be done by
the suid program as well], and this can only be done on filesystems that can
have extended attributes (i.e. no FAT, NFS, etc).
3. Write a suid program that drops all unneeded privileges and then use dlopen
and friends to execute the user code.

I guess that there exists better ways, so somebody please enlighten me.

Regards

Anders Blomdell
-- 
Anders Blomdell                  Email: anders.blomdell@domain.hid
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: [Xenomai-help] Xenomai and capabilities

[Gilles Chanteperdrix]

Anders Blomdell wrote:
> We are planning to extend our use of xenomai to a wider audience at our
> department, and therefore I would like to know which is the better way to let
> users run xenomai programs with a minimum of system privileges, the
> possibilities I can see are:
> 
> 1. Let the user run anything as root; simple but obviously a security nightmare.
> 2. Write a suid program that let's its children inherit the right capabilities
> and then does a seteuid and does an execve; unfortunately this implies that the
> program that is execve'd has the right capabilties set [which has to be done by
> the suid program as well], and this can only be done on filesystems that can
> have extended attributes (i.e. no FAT, NFS, etc).
> 3. Write a suid program that drops all unneeded privileges and then use dlopen
> and friends to execute the user code.
> 
> I guess that there exists better ways, so somebody please enlighten me.

Did you try:
http://www.xenomai.org/index.php/Non-root_RT

-- 
					    Gilles.

Re: [Xenomai-help] Xenomai and capabilities

[Jan Kiszka]

Am 11.10.2010 18:11, Anders Blomdell wrote:
> We are planning to extend our use of xenomai to a wider audience at our
> department, and therefore I would like to know which is the better way to let
> users run xenomai programs with a minimum of system privileges, the
> possibilities I can see are:
> 
> 1. Let the user run anything as root; simple but obviously a security nightmare.
> 2. Write a suid program that let's its children inherit the right capabilities
> and then does a seteuid and does an execve; unfortunately this implies that the
> program that is execve'd has the right capabilties set [which has to be done by
> the suid program as well], and this can only be done on filesystems that can
> have extended attributes (i.e. no FAT, NFS, etc).
> 3. Write a suid program that drops all unneeded privileges and then use dlopen
> and friends to execute the user code.
> 
> I guess that there exists better ways, so somebody please enlighten me.
> 

A bit better, but not perfect:

http://www.xenomai.org/index.php/Non-root_RT

Combining this with mediated hardware access (robust drivers) and
enabling the Xenomai watchdog should provide a reasonably safe&secure
environment.

Jan


-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] Xenomai and capabilities

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Am 11.10.2010 18:11, Anders Blomdell wrote:
>> We are planning to extend our use of xenomai to a wider audience at our
>> department, and therefore I would like to know which is the better way to let
>> users run xenomai programs with a minimum of system privileges, the
>> possibilities I can see are:
>>
>> 1. Let the user run anything as root; simple but obviously a security nightmare.
>> 2. Write a suid program that let's its children inherit the right capabilities
>> and then does a seteuid and does an execve; unfortunately this implies that the
>> program that is execve'd has the right capabilties set [which has to be done by
>> the suid program as well], and this can only be done on filesystems that can
>> have extended attributes (i.e. no FAT, NFS, etc).
>> 3. Write a suid program that drops all unneeded privileges and then use dlopen
>> and friends to execute the user code.
>>
>> I guess that there exists better ways, so somebody please enlighten me.
>>
> 
> A bit better, but not perfect:
> 
> http://www.xenomai.org/index.php/Non-root_RT
> 
> Combining this with mediated hardware access (robust drivers) and
> enabling the Xenomai watchdog should provide a reasonably safe&secure
> environment.

AFAIK, the BIG FAT warning at the bottom of this page still applies. You
can make an environment with no hardware lockups, but secure, I do not
think so. We do not know how Xenomai APIs could be exploited for a
non-root user to become root.


-- 
					    Gilles.

Re: [Xenomai-help] Xenomai and capabilities

[Jan Kiszka]

Am 11.10.2010 18:23, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Am 11.10.2010 18:11, Anders Blomdell wrote:
>>> We are planning to extend our use of xenomai to a wider audience at our
>>> department, and therefore I would like to know which is the better way to let
>>> users run xenomai programs with a minimum of system privileges, the
>>> possibilities I can see are:
>>>
>>> 1. Let the user run anything as root; simple but obviously a security nightmare.
>>> 2. Write a suid program that let's its children inherit the right capabilities
>>> and then does a seteuid and does an execve; unfortunately this implies that the
>>> program that is execve'd has the right capabilties set [which has to be done by
>>> the suid program as well], and this can only be done on filesystems that can
>>> have extended attributes (i.e. no FAT, NFS, etc).
>>> 3. Write a suid program that drops all unneeded privileges and then use dlopen
>>> and friends to execute the user code.
>>>
>>> I guess that there exists better ways, so somebody please enlighten me.
>>>
>>
>> A bit better, but not perfect:
>>
>> http://www.xenomai.org/index.php/Non-root_RT
>>
>> Combining this with mediated hardware access (robust drivers) and
>> enabling the Xenomai watchdog should provide a reasonably safe&secure
>> environment.
> 
> AFAIK, the BIG FAT warning at the bottom of this page still applies. You
> can make an environment with no hardware lockups, but secure, I do not
> think so. We do not know how Xenomai APIs could be exploited for a
> non-root user to become root.

For sure, no one audited the interface for security so far. There is no
hole in design that comes to my mind ATM, but I would be surprised as
well if you couldn't develop any exploit for some bug or missing check.
Still, there is a huge difference between giving anyone root access and
confining Xenomai access this way.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] Xenomai and capabilities

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Am 11.10.2010 18:23, Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> enabling the Xenomai watchdog should provide a reasonably safe&secure
>>> environment.
>> AFAIK, the BIG FAT warning at the bottom of this page still applies. You
>> can make an environment with no hardware lockups, but secure, I do not
>> think so. We do not know how Xenomai APIs could be exploited for a
>> non-root user to become root.
> 
> For sure, no one audited the interface for security so far. There is no
> hole in design that comes to my mind ATM, but I would be surprised as
> well if you couldn't develop any exploit for some bug or missing check.
> Still, there is a huge difference between giving anyone root access and
> confining Xenomai access this way.

I was just reacting to "reasonably secure". The experience proves that
if you do not do any particular effort for security, then your code is
not secure. Not even reasonably.

-- 
					    Gilles.

Re: [Xenomai-help] Xenomai and capabilities

[Jan Kiszka]

Am 11.10.2010 18:49, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Am 11.10.2010 18:23, Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> enabling the Xenomai watchdog should provide a reasonably safe&secure
>>>> environment.
>>> AFAIK, the BIG FAT warning at the bottom of this page still applies. You
>>> can make an environment with no hardware lockups, but secure, I do not
>>> think so. We do not know how Xenomai APIs could be exploited for a
>>> non-root user to become root.
>>
>> For sure, no one audited the interface for security so far. There is no
>> hole in design that comes to my mind ATM, but I would be surprised as
>> well if you couldn't develop any exploit for some bug or missing check.
>> Still, there is a huge difference between giving anyone root access and
>> confining Xenomai access this way.
> 
> I was just reacting to "reasonably secure". The experience proves that
> if you do not do any particular effort for security, then your code is
> not secure. Not even reasonably.

This is no black-or-white domain, and I wouldn't say we spend no effort
on security at all. We do have interest in making the userspace APIs
robust which addresses security up to a certain level as well.

What is still definitely not secure, though, is RTnet as it consequently
lacks any kind of check on user-passed addresses. But that's not
Xenomai's fault (rather mine).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] Xenomai and capabilities

[Anders Blomdell]

On 2010-10-11 18.58, Jan Kiszka wrote:
> Am 11.10.2010 18:49, Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Am 11.10.2010 18:23, Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> enabling the Xenomai watchdog should provide a reasonably safe&secure
>>>>> environment.
>>>> AFAIK, the BIG FAT warning at the bottom of this page still applies. You
>>>> can make an environment with no hardware lockups, but secure, I do not
>>>> think so. We do not know how Xenomai APIs could be exploited for a
>>>> non-root user to become root.
>>>
>>> For sure, no one audited the interface for security so far. There is no
>>> hole in design that comes to my mind ATM, but I would be surprised as
>>> well if you couldn't develop any exploit for some bug or missing check.
>>> Still, there is a huge difference between giving anyone root access and
>>> confining Xenomai access this way.
>>
>> I was just reacting to "reasonably secure". The experience proves that
>> if you do not do any particular effort for security, then your code is
>> not secure. Not even reasonably.
> 
> This is no black-or-white domain, and I wouldn't say we spend no effort
> on security at all. We do have interest in making the userspace APIs
> robust which addresses security up to a certain level as well.
> 
> What is still definitely not secure, though, is RTnet as it consequently
> lacks any kind of check on user-passed addresses. But that's not
> Xenomai's fault (rather mine).
If I understand manpages and code correctly, xenomai is insecure by design (not
a major problem here, I hope), but I had hoped to be able to avoid CAP_SYS_RAWIO
which I think is the biggest security problem (access to /proc/kcore IS scary),
but since CAP_SYS_NICE implies CAP_SYS_RAWIO via shadow.c:
    if (!capable(CAP_SYS_NICE) &&
        (xn_gid_arg == -1 || !in_group_p(xn_gid_arg)))
        return -EPERM;

     wrap_raise_cap(CAP_SYS_NICE);
     wrap_raise_cap(CAP_IPC_LOCK);
     wrap_raise_cap(CAP_SYS_RAWIO);

I will go for the group thing (simple and totally insecure) for now, and put
some more thought into it later on.

Thanks

Anders


-- 
Anders Blomdell                  Email: anders.blomdell@domain.hid
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: [Xenomai-help] Xenomai and capabilities

[Anders Blomdell]

On 2010-10-12 11.25, Anders Blomdell wrote:
> On 2010-10-11 18.58, Jan Kiszka wrote:
>> Am 11.10.2010 18:49, Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Am 11.10.2010 18:23, Gilles Chanteperdrix wrote:
>>>>> Jan Kiszka wrote:
>>>>>> enabling the Xenomai watchdog should provide a reasonably safe&secure
>>>>>> environment.
>>>>> AFAIK, the BIG FAT warning at the bottom of this page still applies. You
>>>>> can make an environment with no hardware lockups, but secure, I do not
>>>>> think so. We do not know how Xenomai APIs could be exploited for a
>>>>> non-root user to become root.
>>>>
>>>> For sure, no one audited the interface for security so far. There is no
>>>> hole in design that comes to my mind ATM, but I would be surprised as
>>>> well if you couldn't develop any exploit for some bug or missing check.
>>>> Still, there is a huge difference between giving anyone root access and
>>>> confining Xenomai access this way.
>>>
>>> I was just reacting to "reasonably secure". The experience proves that
>>> if you do not do any particular effort for security, then your code is
>>> not secure. Not even reasonably.
>>
>> This is no black-or-white domain, and I wouldn't say we spend no effort
>> on security at all. We do have interest in making the userspace APIs
>> robust which addresses security up to a certain level as well.
>>
>> What is still definitely not secure, though, is RTnet as it consequently
>> lacks any kind of check on user-passed addresses. But that's not
>> Xenomai's fault (rather mine).
> If I understand manpages and code correctly, xenomai is insecure by design (not
> a major problem here, I hope), but I had hoped to be able to avoid CAP_SYS_RAWIO
> which I think is the biggest security problem (access to /proc/kcore IS scary),
> but since CAP_SYS_NICE implies CAP_SYS_RAWIO via shadow.c:
>     if (!capable(CAP_SYS_NICE) &&
>         (xn_gid_arg == -1 || !in_group_p(xn_gid_arg)))
>         return -EPERM;
> 
>      wrap_raise_cap(CAP_SYS_NICE);
>      wrap_raise_cap(CAP_IPC_LOCK);
>      wrap_raise_cap(CAP_SYS_RAWIO);
> 
> I will go for the group thing (simple and totally insecure) for now, and put
> some more thought into it later on.
Well, obviously this feature is somewhat broken:

> testprog
Xenomai: binding failed: Cannot allocate memory.

This is what syslog says:
Xenomai: testprog[2367] cannot map MAYDAY page

Running as root works as it should.

/Anders


-- 
Anders Blomdell                  Email: anders.blomdell@domain.hid
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: [Xenomai-help] Xenomai and capabilities

[Anders Blomdell]

On 2010-10-12 12.23, Anders Blomdell wrote:
> On 2010-10-12 11.25, Anders Blomdell wrote:
>> On 2010-10-11 18.58, Jan Kiszka wrote:
>>> Am 11.10.2010 18:49, Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Am 11.10.2010 18:23, Gilles Chanteperdrix wrote:
>>>>>> Jan Kiszka wrote:
>>>>>>> enabling the Xenomai watchdog should provide a reasonably safe&secure
>>>>>>> environment.
>>>>>> AFAIK, the BIG FAT warning at the bottom of this page still applies. You
>>>>>> can make an environment with no hardware lockups, but secure, I do not
>>>>>> think so. We do not know how Xenomai APIs could be exploited for a
>>>>>> non-root user to become root.
>>>>>
>>>>> For sure, no one audited the interface for security so far. There is no
>>>>> hole in design that comes to my mind ATM, but I would be surprised as
>>>>> well if you couldn't develop any exploit for some bug or missing check.
>>>>> Still, there is a huge difference between giving anyone root access and
>>>>> confining Xenomai access this way.
>>>>
>>>> I was just reacting to "reasonably secure". The experience proves that
>>>> if you do not do any particular effort for security, then your code is
>>>> not secure. Not even reasonably.
>>>
>>> This is no black-or-white domain, and I wouldn't say we spend no effort
>>> on security at all. We do have interest in making the userspace APIs
>>> robust which addresses security up to a certain level as well.
>>>
>>> What is still definitely not secure, though, is RTnet as it consequently
>>> lacks any kind of check on user-passed addresses. But that's not
>>> Xenomai's fault (rather mine).
>> If I understand manpages and code correctly, xenomai is insecure by design (not
>> a major problem here, I hope), but I had hoped to be able to avoid CAP_SYS_RAWIO
>> which I think is the biggest security problem (access to /proc/kcore IS scary),
>> but since CAP_SYS_NICE implies CAP_SYS_RAWIO via shadow.c:
>>     if (!capable(CAP_SYS_NICE) &&
>>         (xn_gid_arg == -1 || !in_group_p(xn_gid_arg)))
>>         return -EPERM;
>>
>>      wrap_raise_cap(CAP_SYS_NICE);
>>      wrap_raise_cap(CAP_IPC_LOCK);
>>      wrap_raise_cap(CAP_SYS_RAWIO);
>>
>> I will go for the group thing (simple and totally insecure) for now, and put
>> some more thought into it later on.
> Well, obviously this feature is somewhat broken:
> 
>> testprog
> Xenomai: binding failed: Cannot allocate memory.
> 
> This is what syslog says:
> Xenomai: testprog[2367] cannot map MAYDAY page
> 
> Running as root works as it should.
CAP_DAC_OVERRIDE fixes this issue (and how safe is that :-( )

How necessary are CAP_SYS_RAWIO and CAP_DAC_OVERRIDE [the two capabiltities i
think have the most severe security implications] when main has started running,
i.e. could I drop them after initialization and still do something useful?

/Anders

-- 
Anders Blomdell                  Email: anders.blomdell@domain.hid
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: [Xenomai-help] Xenomai and capabilities

[Gilles Chanteperdrix]

Anders Blomdell wrote:
> CAP_DAC_OVERRIDE fixes this issue (and how safe is that :-( )
> 
> How necessary are CAP_SYS_RAWIO and CAP_DAC_OVERRIDE [the two capabiltities i
> think have the most severe security implications] when main has started running,
> i.e. could I drop them after initialization and still do something useful?

Again: you have just found some reason why Xenomai is unsecure, it just
proves that it is unsecure and there are probably other reasons why it
is unsecure. So, here I do not concur with Jan. Security *is* a
black-and-white domain. Any security hole makes the system unsecure,
there is no gray area, no "partially secure" code.

Either you are ready to make a thourough auditing of the code and plug
all the security holes you find, or you consider Xenomai unsecure.
Plugging two holes you have found and say "I stop now, this is
'reasonably' secure" does not really make sense.

-- 
					    Gilles.

Re: [Xenomai-help] Xenomai and capabilities

[Anders Blomdell]

On 2010-10-12 15.53, Gilles Chanteperdrix wrote:
> Anders Blomdell wrote:
>> CAP_DAC_OVERRIDE fixes this issue (and how safe is that :-( )
>>
>> How necessary are CAP_SYS_RAWIO and CAP_DAC_OVERRIDE [the two capabiltities i
>> think have the most severe security implications] when main has started running,
>> i.e. could I drop them after initialization and still do something useful?
> 
> Again: you have just found some reason why Xenomai is unsecure, it just
> proves that it is unsecure and there are probably other reasons why it
> is unsecure. So, here I do not concur with Jan. Security *is* a
> black-and-white domain. Any security hole makes the system unsecure,
> there is no gray area, no "partially secure" code.
Hence it's essentially a black area, but plugging holes still makes sense in
order to eventually arrive at a secure system.

> Either you are ready to make a thourough auditing of the code and plug
> all the security holes you find, or you consider Xenomai unsecure.
See my questions and comments as a step in this direction, but I am not and will
never be competent enough to find all holes.

> Plugging two holes you have found and say "I stop now, this is
> 'reasonably' secure" does not really make sense.
I totally agree, but plugging the obvious holes is at least not a step backward
in this respect.

CAP_DAC_OVERRIDE -> write anything anywhere in the filesystem
CAP_SYS_RAWIO -> trash memory at will

Does anybody know why these capabilities are required (execept for the MAYDAY page?)

Regards

Anders

-- 
Anders Blomdell                  Email: anders.blomdell@domain.hid
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: [Xenomai-help] Xenomai and capabilities

[Gilles Chanteperdrix]

Anders Blomdell wrote:
> On 2010-10-12 15.53, Gilles Chanteperdrix wrote:
>> Anders Blomdell wrote:
>>> CAP_DAC_OVERRIDE fixes this issue (and how safe is that :-( )
>>>
>>> How necessary are CAP_SYS_RAWIO and CAP_DAC_OVERRIDE [the two capabiltities i
>>> think have the most severe security implications] when main has started running,
>>> i.e. could I drop them after initialization and still do something useful?
>> Again: you have just found some reason why Xenomai is unsecure, it just
>> proves that it is unsecure and there are probably other reasons why it
>> is unsecure. So, here I do not concur with Jan. Security *is* a
>> black-and-white domain. Any security hole makes the system unsecure,
>> there is no gray area, no "partially secure" code.
> Hence it's essentially a black area, but plugging holes still makes sense in
> order to eventually arrive at a secure system.

There are probably huge changes in the code which would be required to
make it secure. I do not want to tackle this issue. It would be a huge
amount of work, only required for very few of Xenomai users. It is not
even on my already long ever-growing todo list. And I suspect it is not
on Philippe's either.

> 
>> Either you are ready to make a thourough auditing of the code and plug
>> all the security holes you find, or you consider Xenomai unsecure.
> See my questions and comments as a step in this direction, but I am not and will
> never be competent enough to find all holes.

Neither am I. Knowing the code is not enough. One more reason to not
even try and tackle this issue.

> 
>> Plugging two holes you have found and say "I stop now, this is
>> 'reasonably' secure" does not really make sense.
> I totally agree, but plugging the obvious holes is at least not a step backward
> in this respect.
> 
> CAP_DAC_OVERRIDE -> write anything anywhere in the filesystem
> CAP_SYS_RAWIO -> trash memory at will

Not really memory, but more MMIO and IOPORTs areas. Many users want
that. It is even required on ARM to have the TSC emulation working.

> 
> Does anybody know why these capabilities are required (execept for the MAYDAY page?)

You really want MAYDAY support if you want the users to be able to
recover from stupid programming error with the help of the watchdog.
Without mayday + watchdog, infinite loop means hard lockup needing reboot.

The point is that since the user able to run Xenomai applications can
break the systems in so many way (simply by using the SCHED_FIFO
scheduling policy, you start being dangerous for the system), why trying
and restricting its powers? It would only get in the way of people for
which security is not an issue.

For instance, if we disable CAP_SYS_RAWIO, it will make it hard for ARM
users to use their platform at its full potential.

-- 
					    Gilles.

Re: [Xenomai-help] Xenomai and capabilities

[Anders Blomdell]

On 2010-10-12 16.57, Gilles Chanteperdrix wrote:
> Anders Blomdell wrote:
>> On 2010-10-12 15.53, Gilles Chanteperdrix wrote:
>>> Anders Blomdell wrote:
>>>> CAP_DAC_OVERRIDE fixes this issue (and how safe is that :-( )
>>>>
>>>> How necessary are CAP_SYS_RAWIO and CAP_DAC_OVERRIDE [the two capabiltities i
>>>> think have the most severe security implications] when main has started running,
>>>> i.e. could I drop them after initialization and still do something useful?
>>> Again: you have just found some reason why Xenomai is unsecure, it just
>>> proves that it is unsecure and there are probably other reasons why it
>>> is unsecure. So, here I do not concur with Jan. Security *is* a
>>> black-and-white domain. Any security hole makes the system unsecure,
>>> there is no gray area, no "partially secure" code.
>> Hence it's essentially a black area, but plugging holes still makes sense in
>> order to eventually arrive at a secure system.
> 
> There are probably huge changes in the code which would be required to
> make it secure. I do not want to tackle this issue. It would be a huge
> amount of work, only required for very few of Xenomai users. It is not
> even on my already long ever-growing todo list. And I suspect it is not
> on Philippe's either.
> 
>>
>>> Either you are ready to make a thourough auditing of the code and plug
>>> all the security holes you find, or you consider Xenomai unsecure.
>> See my questions and comments as a step in this direction, but I am not and will
>> never be competent enough to find all holes.
> 
> Neither am I. Knowing the code is not enough. One more reason to not
> even try and tackle this issue.
> 
>>
>>> Plugging two holes you have found and say "I stop now, this is
>>> 'reasonably' secure" does not really make sense.
>> I totally agree, but plugging the obvious holes is at least not a step backward
>> in this respect.
>>
>> CAP_DAC_OVERRIDE -> write anything anywhere in the filesystem
>> CAP_SYS_RAWIO -> trash memory at will
> 
> Not really memory, but more MMIO and IOPORTs areas. Many users want
> that. It is even required on ARM to have the TSC emulation working.
> 
>>
>> Does anybody know why these capabilities are required (execept for the MAYDAY page?)
> 
> You really want MAYDAY support if you want the users to be able to
> recover from stupid programming error with the help of the watchdog.
> Without mayday + watchdog, infinite loop means hard lockup needing reboot.
> 
> The point is that since the user able to run Xenomai applications can
> break the systems in so many way (simply by using the SCHED_FIFO
> scheduling policy, you start being dangerous for the system), why trying
> and restricting its powers? It would only get in the way of people for
> which security is not an issue.
> 
> For instance, if we disable CAP_SYS_RAWIO, it will make it hard for ARM
> users to use their platform at its full potential.
OK, so short answer is you are root when you run Xenomai (or can easily become
root)?

Fine with me, but it's always good to know.

CAP_DAC_OVERRIDE still needs fixing for
http://www.xenomai.org/index.php/Non-root_RT to work.

Regards

Anders

-- 
Anders Blomdell                  Email: anders.blomdell@domain.hid
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: [Xenomai-help] Xenomai and capabilities

[Gilles Chanteperdrix]

Anders Blomdell wrote:
> OK, so short answer is you are root when you run Xenomai (or can easily become
> root)?
> 
> Fine with me, but it's always good to know.

Yes. I prefer you making this assumption than believing that the system
is mostly secure.

Now, if your concern is for teaching purposes, maybe you can put people
in a "cross-development" situation? They can not break the host machine
running the GUI and where they do the development, and they can break
the target machine at will without much consequences.

> 
> CAP_DAC_OVERRIDE still needs fixing for
> http://www.xenomai.org/index.php/Non-root_RT to work.

Ok. Thanks, will fix.


-- 
					    Gilles.

Re: [Xenomai-help] Xenomai and capabilities

[Philippe Gerum]

On Tue, 2010-10-12 at 16:42 +0200, Anders Blomdell wrote:
> On 2010-10-12 15.53, Gilles Chanteperdrix wrote:
> > Anders Blomdell wrote:
> >> CAP_DAC_OVERRIDE fixes this issue (and how safe is that :-( )
> >>
> >> How necessary are CAP_SYS_RAWIO and CAP_DAC_OVERRIDE [the two capabiltities i
> >> think have the most severe security implications] when main has started running,
> >> i.e. could I drop them after initialization and still do something useful?
> > 
> > Again: you have just found some reason why Xenomai is unsecure, it just
> > proves that it is unsecure and there are probably other reasons why it
> > is unsecure. So, here I do not concur with Jan. Security *is* a
> > black-and-white domain. Any security hole makes the system unsecure,
> > there is no gray area, no "partially secure" code.
> Hence it's essentially a black area, but plugging holes still makes sense in
> order to eventually arrive at a secure system.
> 
> > Either you are ready to make a thourough auditing of the code and plug
> > all the security holes you find, or you consider Xenomai unsecure.
> See my questions and comments as a step in this direction, but I am not and will
> never be competent enough to find all holes.
> 
> > Plugging two holes you have found and say "I stop now, this is
> > 'reasonably' secure" does not really make sense.
> I totally agree, but plugging the obvious holes is at least not a step backward
> in this respect.
> 
> CAP_DAC_OVERRIDE -> write anything anywhere in the filesystem
> CAP_SYS_RAWIO -> trash memory at will

Sloppy design triggered by x86 constraints: mainly to allow people to
call ioperm() for user-space drivers, without having to supply any
kernel code. Opening /dev/mem and friends comes next, but less common.

> 
> Does anybody know why these capabilities are required (execept for the MAYDAY page?)
> 
> Regards
> 
> Anders
> 

-- 
Philippe.

Re: [Xenomai-help] Xenomai and capabilities

[Jan Kiszka]

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

Am 12.10.2010 14:56, Anders Blomdell wrote:
> On 2010-10-12 12.23, Anders Blomdell wrote:
>> On 2010-10-12 11.25, Anders Blomdell wrote:
>>> On 2010-10-11 18.58, Jan Kiszka wrote:
>>>> Am 11.10.2010 18:49, Gilles Chanteperdrix wrote:
>>>>> Jan Kiszka wrote:
>>>>>> Am 11.10.2010 18:23, Gilles Chanteperdrix wrote:
>>>>>>> Jan Kiszka wrote:
>>>>>>>> enabling the Xenomai watchdog should provide a reasonably safe&secure
>>>>>>>> environment.
>>>>>>> AFAIK, the BIG FAT warning at the bottom of this page still applies. You
>>>>>>> can make an environment with no hardware lockups, but secure, I do not
>>>>>>> think so. We do not know how Xenomai APIs could be exploited for a
>>>>>>> non-root user to become root.
>>>>>>
>>>>>> For sure, no one audited the interface for security so far. There is no
>>>>>> hole in design that comes to my mind ATM, but I would be surprised as
>>>>>> well if you couldn't develop any exploit for some bug or missing check.
>>>>>> Still, there is a huge difference between giving anyone root access and
>>>>>> confining Xenomai access this way.
>>>>>
>>>>> I was just reacting to "reasonably secure". The experience proves that
>>>>> if you do not do any particular effort for security, then your code is
>>>>> not secure. Not even reasonably.
>>>>
>>>> This is no black-or-white domain, and I wouldn't say we spend no effort
>>>> on security at all. We do have interest in making the userspace APIs
>>>> robust which addresses security up to a certain level as well.
>>>>
>>>> What is still definitely not secure, though, is RTnet as it consequently
>>>> lacks any kind of check on user-passed addresses. But that's not
>>>> Xenomai's fault (rather mine).
>>> If I understand manpages and code correctly, xenomai is insecure by design (not
>>> a major problem here, I hope), but I had hoped to be able to avoid CAP_SYS_RAWIO
>>> which I think is the biggest security problem (access to /proc/kcore IS scary),
>>> but since CAP_SYS_NICE implies CAP_SYS_RAWIO via shadow.c:
>>>     if (!capable(CAP_SYS_NICE) &&
>>>         (xn_gid_arg == -1 || !in_group_p(xn_gid_arg)))
>>>         return -EPERM;
>>>
>>>      wrap_raise_cap(CAP_SYS_NICE);
>>>      wrap_raise_cap(CAP_IPC_LOCK);
>>>      wrap_raise_cap(CAP_SYS_RAWIO);
>>>
>>> I will go for the group thing (simple and totally insecure) for now, and put
>>> some more thought into it later on.
>> Well, obviously this feature is somewhat broken:
>>
>>> testprog
>> Xenomai: binding failed: Cannot allocate memory.
>>
>> This is what syslog says:
>> Xenomai: testprog[2367] cannot map MAYDAY page
>>
>> Running as root works as it should.
> CAP_DAC_OVERRIDE fixes this issue (and how safe is that :-( )

This is not a Xenomai issue but a system misconfiguration. Installing
the Xenomai-provided udev scripts will fix it (ie. grant your Xenomai
group access to /dev/rtheap).

> 
> How necessary are CAP_SYS_RAWIO and CAP_DAC_OVERRIDE [the two capabiltities i
> think have the most severe security implications] when main has started running,
> i.e. could I drop them after initialization and still do something useful?

In the absence of user space drivers, you should be able to live without
CAP_SYS_RAWIO. Not sure, though, if there is a way to overcome
CAP_SYS_RAWIO for user space TSC access on ARM as Gilles mentioned. But
if that turns out to be the only remaining problem, making this
capability optional (at least on !=ARM) should be no big deal IMHO.

Jan


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

Re: [Xenomai-help] Xenomai and capabilities

[Anders Blomdell]

On 2010-10-12 19.20, Jan Kiszka wrote:
> Am 12.10.2010 14:56, Anders Blomdell wrote:
>> On 2010-10-12 12.23, Anders Blomdell wrote:
>>> On 2010-10-12 11.25, Anders Blomdell wrote:
>>>> On 2010-10-11 18.58, Jan Kiszka wrote:
>>>>> Am 11.10.2010 18:49, Gilles Chanteperdrix wrote:
>>>>>> Jan Kiszka wrote:
>>>>>>> Am 11.10.2010 18:23, Gilles Chanteperdrix wrote:
>>>>>>>> Jan Kiszka wrote:
>>>>>>>>> enabling the Xenomai watchdog should provide a reasonably safe&secure
>>>>>>>>> environment.
>>>>>>>> AFAIK, the BIG FAT warning at the bottom of this page still applies. You
>>>>>>>> can make an environment with no hardware lockups, but secure, I do not
>>>>>>>> think so. We do not know how Xenomai APIs could be exploited for a
>>>>>>>> non-root user to become root.
>>>>>>>
>>>>>>> For sure, no one audited the interface for security so far. There is no
>>>>>>> hole in design that comes to my mind ATM, but I would be surprised as
>>>>>>> well if you couldn't develop any exploit for some bug or missing check.
>>>>>>> Still, there is a huge difference between giving anyone root access and
>>>>>>> confining Xenomai access this way.
>>>>>>
>>>>>> I was just reacting to "reasonably secure". The experience proves that
>>>>>> if you do not do any particular effort for security, then your code is
>>>>>> not secure. Not even reasonably.
>>>>>
>>>>> This is no black-or-white domain, and I wouldn't say we spend no effort
>>>>> on security at all. We do have interest in making the userspace APIs
>>>>> robust which addresses security up to a certain level as well.
>>>>>
>>>>> What is still definitely not secure, though, is RTnet as it consequently
>>>>> lacks any kind of check on user-passed addresses. But that's not
>>>>> Xenomai's fault (rather mine).
>>>> If I understand manpages and code correctly, xenomai is insecure by design (not
>>>> a major problem here, I hope), but I had hoped to be able to avoid CAP_SYS_RAWIO
>>>> which I think is the biggest security problem (access to /proc/kcore IS scary),
>>>> but since CAP_SYS_NICE implies CAP_SYS_RAWIO via shadow.c:
>>>>     if (!capable(CAP_SYS_NICE) &&
>>>>         (xn_gid_arg == -1 || !in_group_p(xn_gid_arg)))
>>>>         return -EPERM;
>>>>
>>>>      wrap_raise_cap(CAP_SYS_NICE);
>>>>      wrap_raise_cap(CAP_IPC_LOCK);
>>>>      wrap_raise_cap(CAP_SYS_RAWIO);
>>>>
>>>> I will go for the group thing (simple and totally insecure) for now, and put
>>>> some more thought into it later on.
>>> Well, obviously this feature is somewhat broken:
>>>
>>>> testprog
>>> Xenomai: binding failed: Cannot allocate memory.
>>>
>>> This is what syslog says:
>>> Xenomai: testprog[2367] cannot map MAYDAY page
>>>
>>> Running as root works as it should.
>> CAP_DAC_OVERRIDE fixes this issue (and how safe is that :-( )
> 
> This is not a Xenomai issue but a system misconfiguration. Installing
> the Xenomai-provided udev scripts will fix it (ie. grant your Xenomai
> group access to /dev/rtheap).
http://www.xenomai.org/index.php/Non-root_RT needs to be fixed, since the
rtheap/rtpipe.rules assumes that the group is named xenomai.

> 
>>
>> How necessary are CAP_SYS_RAWIO and CAP_DAC_OVERRIDE [the two capabiltities i
>> think have the most severe security implications] when main has started running,
>> i.e. could I drop them after initialization and still do something useful?
> 
> In the absence of user space drivers, you should be able to live without
> CAP_SYS_RAWIO. Not sure, though, if there is a way to overcome
> CAP_SYS_RAWIO for user space TSC access on ARM as Gilles mentioned. But
> if that turns out to be the only remaining problem, making this
> capability optional (at least on !=ARM) should be no big deal IMHO.

OK, sounds like it's worth investigating further. I'm not after total security,
but trying to make it harder for students to unintentionally breaking the
[file-]system.

/Anders

-- 
Anders Blomdell                  Email: anders.blomdell@domain.hid
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: [Xenomai-help] Xenomai and capabilities

[Jan Kiszka]

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

Am 12.10.2010 20:01, Anders Blomdell wrote:
> On 2010-10-12 19.20, Jan Kiszka wrote:
>> Am 12.10.2010 14:56, Anders Blomdell wrote:
>>> On 2010-10-12 12.23, Anders Blomdell wrote:
>>>> On 2010-10-12 11.25, Anders Blomdell wrote:
>>>>> On 2010-10-11 18.58, Jan Kiszka wrote:
>>>>>> Am 11.10.2010 18:49, Gilles Chanteperdrix wrote:
>>>>>>> Jan Kiszka wrote:
>>>>>>>> Am 11.10.2010 18:23, Gilles Chanteperdrix wrote:
>>>>>>>>> Jan Kiszka wrote:
>>>>>>>>>> enabling the Xenomai watchdog should provide a reasonably safe&secure
>>>>>>>>>> environment.
>>>>>>>>> AFAIK, the BIG FAT warning at the bottom of this page still applies. You
>>>>>>>>> can make an environment with no hardware lockups, but secure, I do not
>>>>>>>>> think so. We do not know how Xenomai APIs could be exploited for a
>>>>>>>>> non-root user to become root.
>>>>>>>>
>>>>>>>> For sure, no one audited the interface for security so far. There is no
>>>>>>>> hole in design that comes to my mind ATM, but I would be surprised as
>>>>>>>> well if you couldn't develop any exploit for some bug or missing check.
>>>>>>>> Still, there is a huge difference between giving anyone root access and
>>>>>>>> confining Xenomai access this way.
>>>>>>>
>>>>>>> I was just reacting to "reasonably secure". The experience proves that
>>>>>>> if you do not do any particular effort for security, then your code is
>>>>>>> not secure. Not even reasonably.
>>>>>>
>>>>>> This is no black-or-white domain, and I wouldn't say we spend no effort
>>>>>> on security at all. We do have interest in making the userspace APIs
>>>>>> robust which addresses security up to a certain level as well.
>>>>>>
>>>>>> What is still definitely not secure, though, is RTnet as it consequently
>>>>>> lacks any kind of check on user-passed addresses. But that's not
>>>>>> Xenomai's fault (rather mine).
>>>>> If I understand manpages and code correctly, xenomai is insecure by design (not
>>>>> a major problem here, I hope), but I had hoped to be able to avoid CAP_SYS_RAWIO
>>>>> which I think is the biggest security problem (access to /proc/kcore IS scary),
>>>>> but since CAP_SYS_NICE implies CAP_SYS_RAWIO via shadow.c:
>>>>>     if (!capable(CAP_SYS_NICE) &&
>>>>>         (xn_gid_arg == -1 || !in_group_p(xn_gid_arg)))
>>>>>         return -EPERM;
>>>>>
>>>>>      wrap_raise_cap(CAP_SYS_NICE);
>>>>>      wrap_raise_cap(CAP_IPC_LOCK);
>>>>>      wrap_raise_cap(CAP_SYS_RAWIO);
>>>>>
>>>>> I will go for the group thing (simple and totally insecure) for now, and put
>>>>> some more thought into it later on.
>>>> Well, obviously this feature is somewhat broken:
>>>>
>>>>> testprog
>>>> Xenomai: binding failed: Cannot allocate memory.
>>>>
>>>> This is what syslog says:
>>>> Xenomai: testprog[2367] cannot map MAYDAY page
>>>>
>>>> Running as root works as it should.
>>> CAP_DAC_OVERRIDE fixes this issue (and how safe is that :-( )
>>
>> This is not a Xenomai issue but a system misconfiguration. Installing
>> the Xenomai-provided udev scripts will fix it (ie. grant your Xenomai
>> group access to /dev/rtheap).
> http://www.xenomai.org/index.php/Non-root_RT needs to be fixed, since the
> rtheap/rtpipe.rules assumes that the group is named xenomai.
> 

Done.

>>
>>>
>>> How necessary are CAP_SYS_RAWIO and CAP_DAC_OVERRIDE [the two capabiltities i
>>> think have the most severe security implications] when main has started running,
>>> i.e. could I drop them after initialization and still do something useful?
>>
>> In the absence of user space drivers, you should be able to live without
>> CAP_SYS_RAWIO. Not sure, though, if there is a way to overcome
>> CAP_SYS_RAWIO for user space TSC access on ARM as Gilles mentioned. But
>> if that turns out to be the only remaining problem, making this
>> capability optional (at least on !=ARM) should be no big deal IMHO.
> 
> OK, sounds like it's worth investigating further. I'm not after total security,
> but trying to make it harder for students to unintentionally breaking the
> [file-]system.

I assumed so. You won't get much DoS protection (though cgroups might be
worth considering to confine SYS_CAP_NICE effects on the Linux side),
but you should be able to avoid frequent re-installations due to user
mistakes or "vandalism" of moderately skilled attackers.

Jan


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