On Mon, 1 Dec 2003 07:43, Andreas Barth <[EMAIL PROTECTED]> wrote: > > 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.
Actually this should already work. Drop files under /usr/share/selinux/policy/default and then run /usr/sbin/selinux-update if it exists and you should get most of what you want. > > 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). Getty policy is pretty simple. Get run from init, open a terminal device, then spawn /bin/login. fbgetty requires one extra capability than other getty's, but fbgetty should be considered deprecated anyway. > > 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? "password file" in that context meant the file containing the password (IE /etc/shadow in the case of system authentication), not the misnamed /etc/passwd. But really I was referring to general user stuff. Such as gpg and it's secret key file, the POP password stored for the MUA, etc. > > 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? Yes! > Putting a file in /etc/logrotate.d is not considered "usage of cron"? A logrotate file is considered use of cron. Logrotate has to be given permission to access the log files etc on it's own, or a script has to be launched with a domain transition to do things (or both). > 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. I imagine that if you document the basic functionality of your package and make sure it does no silly things then things will be easier for people using grsec too. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]