Re: [Xenomai-help] Xenomai and capabilities

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- 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 --]