* Michael A. Halcrow (mahalcro@private) wrote: > > Right. We've actually flip-flopped between using CAP_SYS_MODULE and a > custom hook a couple of times. I don't recall exactly why we stayed > with the hook rather than the capability, so I'm changing it back to > the capability (until Serge complains). Heh, ok, sounds good. > No, I'm afraid that this would *never* work. There are mismatched > parenthesis. :-P Okay, I've put something like this in place of what > was there. Thanks for the suggestion. Ah, yes. Tried to slip this one past the parenthesis police ;-) > I ripped that check out nonetheless, and it still works the way we > expect; CAP_SYS_RAWIO does seem to be taking care of writes to > /dev/mem and /dev/kmem. We had a lot of redundancy in an earlier > incarnation of seclvl, and this one slipped past our redundancy > checks. I believe it's dead code, as the combo of S_IFBLK and the mem char devices are mutually exclusive. Glad it's still working correctly. > > This latter check could break the case where you set a file for > > mandatory locking. Not sure if that's intentional. > > seclvl disallows many actions. As long as there are no actions that > get through that shouldn't, we have no qualms about that. If there is > an elegant way to not break so many things (without adding new hooks, > preferably), we're all ears. Specifically, capabilities are very much > blanket policies, and while they cover Secure Level policies too, > we're happy. In the meantime, anything that doesn't work will be > documented. Which reminds me, I need to write that. The case (S_ISGID & ~S_IXGRP), as distinct from the more normal case (S_ISGID | S_IXGRP), is a case where the sgid bit is either worthless, or is being used to flag the file for use with mandatory locking. So, you may consider checking the mode for both bits instead of just the S_ISGID bit. > That was an artifact from an earlier implementation of the module last > year. We never really questioned its appropriateness as it relates to > recent changes in the kernel (until now). Fair enough. > I have read through kobject.txt and sysfs.txt and am in the process of > revising the module accordingly. We could consider somehting that's come up before, which is to make something like sys/security as a place to register module specific attributes. > We'll look into this. My personal preference is to implement a > password-based seclvl reduction rather than to link it to an > executable file (echo "abracadabra" > /sysfs/security/seclvl). Now > that I think about it, this would be a great opportunity to use the > MD5 code that's now in the kernel ;-). This looks like something that could easily be hooked up to the setprocattr interface. > As far as the flooding issue goes, will the ``quiet'' and ``noisy'' > verbosity levels be acceptable to address that issue? On my Debian > box (2.6.0-test9 kernel, sysklogd version 1.4.1), duplicate messages > are written to the logs as ``last message repeated 5 times''. What > further measures can be reasonably expected from us to address log > file flooding threats? You could rate limit the messages before they get put into kernel buffer. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
This archive was generated by hypermail 2b30 : Tue Nov 25 2003 - 19:03:32 PST