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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
