On Fri, Jul 19, 2002 at 08:18:12PM -0700, Linus Torvalds wrote: > > > On Fri, 19 Jul 2002, Greg KH wrote: > > > > It includes the default capabilities module, which should > > be selected in the kernel configuration if you want to keep the existing > > "normal Linux" capabilities mode. > > Greg, may I suggest one more changeset that sets > > define_bool CONFIG_SECURITY_CAPABILITIES y > > and thus people would have to explicitly disable it by editing the > config.in files to not get the capabilities we already expect.. Ok, as this is confusing, I have made this change. Please pull from: bk://lsm.bkbits.net/linus-2.5 ChangeSetat_private, 2002-07-19 22:55:26-07:00, gregat_private LSM: for now, always set CONFIG_SECURITY_CAPABILITIES to y This can be overridden by editing the .config file if you really want it. security/Config.in | 1 + 1 files changed, 1 insertion(+) > In particular, for all I know there may be programs like sendfile that > depend on capabilities today, and while they may abort gracefully without > them, I do absolutely _not_ want to be in the situation where people can, > by mistake, end up in a situation where they think they are secure, but > their programs depend on security that they have disabled. > > Alternatively, just explain to me why this is a non-issue. I looked at the > patches, but without delving into them much more deeply I just don't have > the background. It's not really a non-issue. If you do not enable the above config option right now, you get a working kernel, and a working capable() call. It's just that every time you ask capable() if the task has this specific capability, it responds with "yes". So capabilities still work properly (like for programs such as sendmail), it's just that every user is essentially root :) When building other security modules (like SELinux as an example), you want to build the capabilities code as a module, which SELinux then loads on top of itself, preserving the original capable() functionality, and possibly tightening it. So for now, I agree, I don't want people to make an easy mistake that causes their machines to be insecure accidentally. If we ever start adding security modules to the tree, then we should think about making it a bit easier to select the capabilities code as a module. Does this sound ok? thanks, greg k-h _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Jul 19 2002 - 22:58:38 PDT