Re: LSM-based systems and debian packages
On Mon, 1 Dec 2003 07:43, Andreas Barth <aba@not.so.argh.org> 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
Reply to: