[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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?


> 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: