Here's the response I got from Suse on my question about Bastille:
many thanks for your enquiry to SuSE S/390 support.
You wrote:
> As part of our evaluation of SLES8 as an internet-facing platform, I attempted
> to run the RPM-provided "bastille" against our standard-build server.
> [..]
Unfortunately, we do not support Bastille for several reasons. The main
one is, that it is trying to enforce its own permission settings to
several components beyond our control. We simply do not know for
sure what it is doing.
However, SuSE Linux has its own permission control scheme which
can be configured through
/etc/sysconfig/security
with different sets of parameters in
/etc/permission*
/etc/permission.d/*
(the reference to "rc.config" should be "/etc/sysconfig/security"
in the comments)
You can set the permissions by running "SuSEconfig" or
"chkstat -set ..."
> Executing File Permissions Specific Configuration
> Bareword "chkstat" not allowed while "strict subs" in use at
> /usr/lib/Bastille/FilePermissions.pm line 306.
Personally, I wouldn't trust a security checking program that does
not even declare its functions properly... On the other hand,
they are running it in strict mode at least. YMMV, though.
Best regards,
Joerg Reuter (S390 Support <[EMAIL PROTECTED]>)
SuSE S/390 Professional Services-Team
> -----Original Message-----
> From: Linux on 390 Port [mailto:[EMAIL PROTECTED]
> Behalf Of Vic
> Cross
> Sent: Tuesday, February 03, 2004 9:19 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [LINUX-390] Bastille-Linux for SuSE
>
>
> G'day Mark,
>
> On Tue, 3 Feb 2004, Post, Mark K wrote:
>
> > Because if they don't, then they'll get the same complaints
> that Red Hat has
> > been getting with RHEL3:
> > Q - Why isn't the so-and-so RPM included in RHEL any more?
> > A - It isn't supported, so we took it out. It's never been
> supported but we
> > kept having to tell people that over, and over, and over again.
> > Q - Well, I understand that it's not supported, but I don't
> want to have to
> > build it myself. Can't you put it back in?
> >
> > It's a no-win situation for the distribution creators.
>
> Sure: I don't envy the job of the distribution maintainers!
> But what if
> the dropped package means that the customer loses functionality?
>
> We had exactly this scenario recently: dhcpcd was dropped
> between RH 7.2
> and RHEL 3.0, to be replaced by dhclient. Okay, fine, at one
> stage RH was
> supporting at least three DHCP client packages and wanted to
> pick one to
> go forward with. However, dhclient does not support the
> "broadcast reply
> flag" that is required for DHCP to work on a Guest LAN. Dropping that
> package means that out-of-the-box, a RHEL 3.0 guest cannot
> use DHCP on a
> Guest LAN -- which is especially ironic because the installer
> in RHEL 3.0
> now gives us the option of configuring interfaces using DHCP!
>
> The support aspect is a different angle. I would have
> assumed, like many,
> that whatever was on the CDs would get some level of support
> by the distro
> vendor. If that's not -- was never -- the case, I can understand the
> desire to rationalise the packages lists so that such an
> assurance could
> be given in the future.
>
> I agree that it's a no-win situation, but can't help but think that it
> needs to be managed better. Sorry guys! :-)
>
> Hoo-roo,
> Vic Cross
>
