From: Kamil K. <ka...@ka...> - 2006-01-09 14:13:10
|
Hello. Like many others, I had problem with inability to use 2 lsm modules at the same time - trustees and capabilities together. There're many applications which rely on capabilities - in my case I needed Bind 9 running on system with trustees enabled. This was very urgent to me, so I had no choice but to patch the kernel. Please note that my solution is really a hack, not the proper implementation. I did the whole thing in 12h, including research on lsm inner workings, which I know little about, it wasn't properly tested and could crash your server, give everyone root access or make your microwave explode - you've been warned. Use this on production server only if you understand those pretty straight-forward changes and/or you're really pressed against the wall with this issue. It's running on 2 of my production servers for a week now without problems, but there're no guarantees. There are several approaches to the problem - I choosed attaching trustees as a secondary module to capabilities module. This is the least elegant solution, because it involves patching capabilities module, but is the simplest one to implement(less hooks to serve - less places to break something). For permanent solution it'd be better make trustees primary module and allow attaching capability as secondary - as selinux does. Maybe the project maintainer will choose this way for official implementation. Patches against 2.6.14.3 and trustees 3.0 are available here: http://kamil.eisp.pl/trustees Patch against trustees module is trivial and just allows it to register as secondary module. Most of the code has been ripped from other lsm modules - capability, selinux etc. After applying the patches, you must load capability module and then trustees module - the order is important. Hope this will help someone. Regards. -- Kamil Kaczkowski ka...@ka... |
From: Andrew R. <ae...@ks...> - 2006-01-13 15:54:23
|
On Mon, Jan 09, 2006 at 03:12:56PM +0100, Kamil Kaczkowski wrote: > There are several approaches to the problem - I choosed attaching > trustees as a secondary module to capabilities module. This is the > least elegant solution, because it involves patching capabilities > module, but is the simplest one to implement(less hooks to serve - > less places to break something). For permanent solution it'd be > better make trustees primary module and allow attaching capability as > secondary - as selinux does. Maybe the project maintainer will choose > this way for official implementation. I actually just committed a different implementation. Capabilities at some point was put into a commoncap.c, the actual capabilities module is a small wrapper around commoncap.c. Other modules like root_plug.c simply supply capabilities by wrapping around this file as well. If you check out the latest svn of trustees, it should provide all the functionality of the normal capabilities module. I haven't tested it a whole lot yet, but the simplicity of using commoncap is so much that I don't foresee any problems. As a reminder, the svn command is: svn co https://aeruder.ath.cx:7778/svn/trustees/trunk trustees or just svn update if you've already checked it out. I don't have any programs setup that absolutely depend on capabilities, but I did do some testing with lcap (btw, it is really easy to end up having to force-reboot if you play around with lcap too much -- i completely locked root out of the system, oops :)) Any reports on success are much appreciated, sorry it took me so long to get around to doing this. I best be off to class, only got 30 minutes to get ready and drive a few miles. ;) - Andy -- Andrew Ruder http://www.aeruder.net |
From: Kamil K. <ka...@ka...> - 2006-01-13 19:07:36
|
On Fri, 13 Jan 2006, Andrew Ruder wrote: > I actually just committed a different implementation. Capabilities at > some point was put into a commoncap.c, the actual capabilities module is > a small wrapper around commoncap.c. Other modules like root_plug.c > simply supply capabilities by wrapping around this file as well. If you > check out the latest svn of trustees, it should provide all the > functionality of the normal capabilities module. I haven't tested it a > whole lot yet, but the simplicity of using commoncap is so much that I > don't foresee any problems. > > As a reminder, the svn command is: > svn co https://aeruder.ath.cx:7778/svn/trustees/trunk trustees Hi, it's nice to here from you. Your implementation seems fine with one exception - commoncap code shouldn't be included in trustees module for at least 2 reasons: 1. The need to synchronize commoncap code with changes in kernel code - this may break compability for future kernel versions. 2. Some patches modify commoncap - I'm using grsecurity, which does not use LSM and introduce it's own hooks in capabilities code - grsec won't work properly if trustees implements it's own capability code. Of course it's harder to get it right that way because of dependencies. My suggestion: If someone wants capability and trusteees, the proper way is to configure SECURITY_CAPABILITIES as module - that way we have commoncap module compiled for our use - capability module is to be ignored. In trustees code there should be a #ifdef for SECURITY_CAPABILITIES - if it's enabled in kernel, we set capabilities hooks and act as as proxy between kernel and commoncap module, otherwise we handle only cap_capable, as in trustees 3.0 That way trustees module could be compiled with or without capabilities. What do you think? Regards. P.S. My coworker is currently fighting with the SMP oops bug I described on trustees-general last month. I hope we'll be able to provide a patch for that soon. -- Kamil Kaczkowski ka...@ka... |