Re: LSM-based systems and debian packages
Hi,
thanks for your fast reply. Just a few more questions:
* Russell Coker (russell@coker.com.au) [031130 21:10]:
> On Mon, 1 Dec 2003 04:27, Andreas Barth <aba@not.so.argh.org> 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
Reply to: