Hi, thanks for your fast reply. Just a few more questions:
* Russell Coker ([EMAIL PROTECTED]) [031130 21:10]: > On Mon, 1 Dec 2003 04:27, Andreas Barth <[EMAIL PROTECTED]> wrote: > > Is it possible for me as a package maintainer to specifiy the needed > > rights for "my" programms in a way that as much systems as possible > > can use these without the need for a sysadmin to change anything? Or > > would each LSM-based system need it's own configuration? And if so, > > which should be supported by a package, and how? > There will be support in RPM for packages that contain SE Linux policy. For > Debian such support will come later (if at all) as the plan is to centrally > manage all policy for free software, and it's not difficult to apply custom > policy for non-free software. Managing at one place is IMHO a disadvantage for e.g. backported packages, extra packages, ... I would have favored some central place like /usr/share/lintian/overrides is for lintian where every package could drop it's special file - but of course, if the persons with more wisdom decide this than it's ok from my point of view, and I'll follow this. > There are patches for cron, xdm type programs, procps, psmisc, pam, and > logrotate for SE Linux which will hopefully get accepted into Debian packages > soon. What about the gettys? I'm asking this because I wrote the initial mail because of mgetty, a package where I expect some non-standard setup (though of course, I could be wrong, as I don't know much about this topic). > The best thing at the moment is to do things that are good for security even > on non-SE Linux machines. Don't have the daemon re-write it's own config > files in /etc. Have a separate process to access password files and > manipulate data from them. /etc/passwd (or more exact: getpwuid etc) is not considered a password file, isn't it? > Don't copy files into a chroot for every > invocation (Postfix is difficult because of this), or if you must copy such > files around then make it easy to discover where it is to modify the process > (Postfix startup scripts are difficult to understand and manage). > > Documentation on exactly what cron jobs do would be good too, as they are > particularly painful to get right. You mean: Just standard "good behaviour" for maintability of code? Putting a file in /etc/logrotate.d is not considered "usage of cron"? Some remark about another mail I got in private: It's not that I want to do only something for LSM-based systems. I'll try to support any security enhancement that's in Debian. So I'll certainly do something for SELinux if this is needed, as SELinux runs with the standard kernel and is compatible with LSM (which itself is approved by Linus, and I'm certainly not in the position to overrule Linus decisions). If it's also usefull to do something for grsecurity, I would also do this; however, it would be _really_ usefull if the grsecurity-patch would be compatible with the standard Debian kernel. Talking about what should be done to improve security is always a nice thing. However, much more important is to actually _do_ something (and "do" could of course include, but is not limited to making good proposals). If someone stands up and says: "I'll handle grsecurity, so that it applys cleanly to the Debian kernel, and try to solve problems with any application", I would applaude to it, and do everything I can that a grsecurity-kernel is included in Sarge, and that as much as possible applications are prepared for grsecurity. However, if I face a situation where SELinux is probably included in Sarge in an almost mature setup, and grsecurity even doesn't apply cleanly to a standard Debian kernel, I'll of course first handle SELinux, and then grsecurity. Please don't see this as any judgement of better fitness of any of these security setups. And if you want to change my preferences: Any of you could do that: Just step forward, provide a clean grsecurity-patch, and provide the necessary infos for the package maintainers what they should do. I'd love to integrate support for as many security enhancements as possible, and it's always good if the users of debian have something to choose from. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
