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