New Server, considering hardened, need pointers to tfm...

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

New Server, considering hardened, need pointers to tfm...

tanstaafl-2
Hello all,

I'm considering rolling out a new server with gentoo, but wanted to base
it on the hardened profile, but the gentoo docs I've read so far all
seem to be a bit vague about all the details.

I've been using gentoo for a while on my hobby server, but I installed
it about 8 years ago, and chose the 'server' profile, and I must say it
has been a real pleasure to maintain, with the only real hiccup I ever
experienced being the mailman update that moved the directories for the
lists without telling me what to do about it (the fix was simple, and
the devs swiftly fixed the lack of post-install docs).

Does anyone know of a good How-To that covers *all* of the bases? Ie,
which model is best - grsecurity, PAX, SeLinux - and how best to
implement it?

The purpose of this server will be as a mail server (dovecot, postfix,
amavisd-new/spamassassin, mailman), and hosting a few small websites.

Thanks...

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Matthew Thode (prometheanfire)
On Sat, 10 Dec 2011 15:17:47 -0500
Tanstaafl <[hidden email]> wrote:

> Hello all,
>
> I'm considering rolling out a new server with gentoo, but wanted to
> base it on the hardened profile, but the gentoo docs I've read so far
> all seem to be a bit vague about all the details.
>
> I've been using gentoo for a while on my hobby server, but I
> installed it about 8 years ago, and chose the 'server' profile, and I
> must say it has been a real pleasure to maintain, with the only real
> hiccup I ever experienced being the mailman update that moved the
> directories for the lists without telling me what to do about it (the
> fix was simple, and the devs swiftly fixed the lack of post-install
> docs).
>
> Does anyone know of a good How-To that covers *all* of the bases? Ie,
> which model is best - grsecurity, PAX, SeLinux - and how best to
> implement it?
>
> The purpose of this server will be as a mail server (dovecot,
> postfix, amavisd-new/spamassassin, mailman), and hosting a few small
> websites.
>
> Thanks...
>
As with most things gentoo, 'best' is a mater of opinion.  I personally
use grsec (includes pax) for hardening and selinux for policies.  To
convert you generally do the following.

profile-config set 12 (this sets to nomultilib selinux)
emerge system
emerge world

Since I'm paranoid revdep-rebuild too.

--
Matthew Thode (prometheanfire)

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Sven Vermeulen
On Sat, Dec 10, 2011 at 02:52:04PM -0600, Matthew Thode wrote:
> As with most things gentoo, 'best' is a mater of opinion.  I personally
> use grsec (includes pax) for hardening and selinux for policies.  To
> convert you generally do the following.
>
> profile-config set 12 (this sets to nomultilib selinux)
> emerge system
> emerge world
>
> Since I'm paranoid revdep-rebuild too.

If you're considering SELinux, please follow the instructions at
http://hardened.gentoo.org/selinux/selinux-handbook.xml?part=2&chap=1

There's a little more to it than emerge system/world:
- Your /tmp might need a specific mount option (in /etc/fstab)
- If you use LVM or XFS, you need to take specific measures if you want your
  system to bootup properly
- You need to build a SELinux-aware kernel as well
- You need to install SELinux utilities
- You need to relabel the system
etc.

That said, my opinion on a server is the same as with Matthew: use hardened
with the options given (grsec, selinux) and perhaps even TPE (trusted path
execution).

Also consider hardening your system settings-wise. I would appreciate if you
take a look at
http://dev.gentoo.org/~swift/docs/previews/oval/gentoo-xccdf-guide.html.
With the instructions given, you can even have your system validated (as far
as possible) automatically.

Wkr,
        Sven Vermeulen

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Alex Efros-4
Hi!

On Sun, Dec 11, 2011 at 10:18:51AM +0000, Sven Vermeulen wrote:
> Also consider hardening your system settings-wise. I would appreciate if you
> take a look at
> http://dev.gentoo.org/~swift/docs/previews/oval/gentoo-xccdf-guide.html.

Some points at that guide looks strange to me. For example:

1)  How can
        4.2.4.1. Root Logon Through SSH Is Not Allowed
    increase security, if we're already using
        4.2.4.2. Public Key Authentication Only
    Disabling root may have sense with password auth, but with keys it is
    just useless inconvenience.

2)  How can
        4.2.4.6. Listen on Management Interface
    increase security? Moreover, on multihomed systems listening on all
    interfaces may help you a lot in case one of network link is broken.

3)  In my experience, the
        4.4.2.2. Enable Source Route Verification
    often conflict with net-misc/openvpn based VPN interfaces. I didn't
    investigated this issue in deep, just google for issue and found
    solution which was to disable source route verification, and it works.
    Maybe there is exists better way to solve this issue, not sure.

4)  Nowadays, in addition to
        4.8.2. Limit Setuid and Setgid File and Directory Usage
    we've to also check for SECURITY_FILE_CAPABILITIES and `getcat`.

5)  In my experience, while
        4.8.5. Review File Integrity Regularly
    looks like good idea, it's nearly impossible to use in Gentoo because
    of daily updates which change a lot of system files, so it's too hard
    to review aide-like tool reports and quickly detect suspicious file
    changes. If anyone have a good recipe how to work around this I'll be
    glad to learn it.

--
                        WBR, Alex.

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Sven Vermeulen
On Sun, Dec 11, 2011 at 02:20:43PM +0200, Alex Efros wrote:

> On Sun, Dec 11, 2011 at 10:18:51AM +0000, Sven Vermeulen wrote:
> > Also consider hardening your system settings-wise. I would appreciate if you
> > take a look at
> > http://dev.gentoo.org/~swift/docs/previews/oval/gentoo-xccdf-guide.html.
>
> Some points at that guide looks strange to me. For example:
>
> 1)  How can
> 4.2.4.1. Root Logon Through SSH Is Not Allowed
>     increase security, if we're already using
> 4.2.4.2. Public Key Authentication Only
>     Disabling root may have sense with password auth, but with keys it is
>     just useless inconvenience.

I read somewhere that security is about making things more inconvenient for
malicious people than for authorized ones.

For me, immediately logging in as root is not done. I want to limit root
access through the regular accounts on the system (with su(do)). I never had
the need to log on as root immediately myself.

> 2)  How can
> 4.2.4.6. Listen on Management Interface
>     increase security? Moreover, on multihomed systems listening on all
>     interfaces may help you a lot in case one of network link is broken.

True, but by only allowing management activities on the management interface
and not on a more public facing network, you reduce the likelihood that this
service is abused for malicious reasons.

Personally, I don't limit this on my systems because I don't really have a
multi-homed setup and I am not (yet) considering creating one. Just like
most hardening guides, it is meant to provide some insight in what can be
done - there are always reasons why a setting isn't good for your situation.

> 3)  In my experience, the
> 4.4.2.2. Enable Source Route Verification
>     often conflict with net-misc/openvpn based VPN interfaces. I didn't
>     investigated this issue in deep, just google for issue and found
>     solution which was to disable source route verification, and it works.
>     Maybe there is exists better way to solve this issue, not sure.

Ah, didn't realise that. I'll look into this and if necessary, mention that
OpenVPN might require that this is disabled.

> 4)  Nowadays, in addition to
> 4.8.2. Limit Setuid and Setgid File and Directory Usage
>     we've to also check for SECURITY_FILE_CAPABILITIES and `getcat`.

I still need to look into capabilities. I know Anthony was considering
updating Gentoo/Portage to have this support elevated.

> 5)  In my experience, while
> 4.8.5. Review File Integrity Regularly
>     looks like good idea, it's nearly impossible to use in Gentoo because
>     of daily updates which change a lot of system files, so it's too hard
>     to review aide-like tool reports and quickly detect suspicious file
>     changes. If anyone have a good recipe how to work around this I'll be
>     glad to learn it.

It of course depends on how you manage your system. I can imagine that you
do not want to pull in daily updates on a server, but instead rely on other
hardening measures, glsa-check, cvechecker and the like to mitigate risks of
vulnerabilities.

Thanks a lot for the feedback though, really appreciated!

Wkr,
        Sven Vermeulen

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Alex Efros-4
Hi!

On Sun, Dec 11, 2011 at 02:25:19PM +0000, Sven Vermeulen wrote:

> > 1)  How can
> > 4.2.4.1. Root Logon Through SSH Is Not Allowed
> >     increase security, if we're already using
> > 4.2.4.2. Public Key Authentication Only
> >     Disabling root may have sense with password auth, but with keys it is
> >     just useless inconvenience.
>
> I read somewhere that security is about making things more inconvenient for
> malicious people than for authorized ones.
>
> For me, immediately logging in as root is not done. I want to limit root
> access through the regular accounts on the system (with su(do)). I never had
> the need to log on as root immediately myself.

Understood. But I still don't see how this can increase security.

> hardening measures, glsa-check, cvechecker and the like to mitigate risks of

Been there, done that, it doesn't work: in average, after 1-1.5 years of
security-only updates we end with next one security update which depends
on few other packages which in turn pull in 80% of other @world updates.
So we've to emerge world anyway every ~1.5 years, but such delayed
updates wasn't tested by anyone and usually gives a lot of troubles
resulting in server offline for several days. Daily world updates are much
ease to manage, even with needs to check these updates on test servers
first, before updating production servers. (And daily updates usually easy
to rollback and debug in case of unexpected troubles.) Because of this I
don't think Gentoo is capable to act as LTS-release with security-only
updates like some other distributives.

--
                        WBR, Alex.

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Matthew Thode (prometheanfire)
On Sun, 11 Dec 2011 16:53:02 +0200
Alex Efros <[hidden email]> wrote:

> Hi!
>
> On Sun, Dec 11, 2011 at 02:25:19PM +0000, Sven Vermeulen wrote:
> > > 1)  How can
> > > 4.2.4.1. Root Logon Through SSH Is Not Allowed
> > >     increase security, if we're already using
> > > 4.2.4.2. Public Key Authentication Only
> > >     Disabling root may have sense with password auth, but with
> > > keys it is just useless inconvenience.
> >
> > I read somewhere that security is about making things more
> > inconvenient for malicious people than for authorized ones.
> >
> > For me, immediately logging in as root is not done. I want to limit
> > root access through the regular accounts on the system (with
> > su(do)). I never had the need to log on as root immediately myself.
>
> Understood. But I still don't see how this can increase security.
>
> > hardening measures, glsa-check, cvechecker and the like to mitigate
> > risks of
>
> Been there, done that, it doesn't work: in average, after 1-1.5 years
> of security-only updates we end with next one security update which
> depends on few other packages which in turn pull in 80% of other
> @world updates. So we've to emerge world anyway every ~1.5 years, but
> such delayed updates wasn't tested by anyone and usually gives a lot
> of troubles resulting in server offline for several days. Daily world
> updates are much ease to manage, even with needs to check these
> updates on test servers first, before updating production servers.
> (And daily updates usually easy to rollback and debug in case of
> unexpected troubles.) Because of this I don't think Gentoo is capable
> to act as LTS-release with security-only updates like some other
> distributives.
>
Well, you don't wait years, just months between updates.  I have
glsa-check running daily on my systems and update when it tells me to.
On top of that I update at least monthly, usually weekly (though I
could probably go every six months and be fine).

--
Matthew Thode (prometheanfire)

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Hilco Wijbenga
In reply to this post by Alex Efros-4
On 11 December 2011 06:53, Alex Efros <[hidden email]> wrote:

> On Sun, Dec 11, 2011 at 02:25:19PM +0000, Sven Vermeulen wrote:
>> > 1)  How can
>> >     4.2.4.1. Root Logon Through SSH Is Not Allowed
>> >     increase security, if we're already using
>> >     4.2.4.2. Public Key Authentication Only
>> >     Disabling root may have sense with password auth, but with keys it is
>> >     just useless inconvenience.
>>
>> I read somewhere that security is about making things more inconvenient for
>> malicious people than for authorized ones.
>>
>> For me, immediately logging in as root is not done. I want to limit root
>> access through the regular accounts on the system (with su(do)). I never had
>> the need to log on as root immediately myself.
>
> Understood. But I still don't see how this can increase security.

It is my understanding this is not so much about security per se as it
is about auditing. Especially in an environment with more than one
admin.

Let's say there are two admins (A and B) who both log on (remotely) as
root. Then there is no easy way to tell who did what. Leaving an audit
trail is useful and in many environments simply required.

Moreover, if admin A's account is compromised then a black hat can use
admin A's access to root to remotely log on to any machine admin A has
access to. This will be hard to detect and it will be hard(er) to
determine how the black hat gained access. If admin A had logged on as
admin A instead of root then it would be more obvious it was admin A's
account that had been compromised.

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

ma1l1ists
In reply to this post by Alex Efros-4
On Sun, 11 Dec 2011 16:53:02 +0200
Alex Efros wrote:

> Hi!
>
> On Sun, Dec 11, 2011 at 02:25:19PM +0000, Sven Vermeulen wrote:
> > > 1)  How can
> > > 4.2.4.1. Root Logon Through SSH Is Not Allowed
> > >     increase security, if we're already using
> > > 4.2.4.2. Public Key Authentication Only
> > >     Disabling root may have sense with password auth, but with keys it is
> > >     just useless inconvenience.
> >
> > I read somewhere that security is about making things more inconvenient for
> > malicious people than for authorized ones.
> >
> > For me, immediately logging in as root is not done. I want to limit root
> > access through the regular accounts on the system (with su(do)). I never had
> > the need to log on as root immediately myself.
>
> Understood. But I still don't see how this can increase security.
>

Defense in Depth, I disable root in >4 different ways.

shell
pam
ssh_config
securetty
suid + setcap
rbac
chattr + immutable syscall turn off

It may not help against root exploits but it makes life a little more
difficult for priv escalation.

It may take more work to iron out any diffciulties (short lived) but if
you try to imagine the exploits rather than using minimal
footprint/priviledges then you won't get that nice feeling of, hee hee
doesn't affect me, nearly so often ;-). You'd be surprised, there's
been lots of times where I've thought this is pointless and yet it's
paid off eventually.


>>5)  In my experience, while
>> 4.8.5. Review File Integrity Regularly
>>   looks like good idea, it's nearly impossible to use in Gentoo because
>>    of daily updates which change a lot of system files, so it's too hard
>>    to review aide-like tool reports and quickly detect suspicious file
>>    changes. If anyone have a good recipe how to work around this I'll be
>>    glad to learn it.


The king of this for full pc (x86 etc.) is OpenBSD, though package
updates are more work. I have NEVER had to upgrade the kernel on an
OpenBSD system due to security problems. (Only because I had disabled
ipv6 where it wasn't needed though, which re-affirms the above. I would
guess you would have said disabling ipv6 where it is not needed to be
just a hindrance and not anything to do with security and yet it
accounts for one of the only remote exploits on OpenBSD at default in
more than a decade and meant that I could leave my systems humming away,
rather than getting hot and bothered). In fact some of them could have
been left untouched untill now if it wasn't for the want to upgrade.

Of course an attacker who modifies files isn't very good these
days. Though they are the ones you may catch.

p.s. There really should be a central linux kernel security problem
site as the work of necessarily good people seems duplicated at the
moment?


Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

ma1l1ists
In reply to this post by Sven Vermeulen
On Sun, 11 Dec 2011 10:18:51 +0000
Sven Vermeulen wrote:

> Also consider hardening your system settings-wise. I would appreciate if you
> take a look at
> http://dev.gentoo.org/~swift/docs/previews/oval/gentoo-xccdf-guide.html.
> With the instructions given, you can even have your system validated (as far
> as possible) automatically.

I was expecting to find here what one distro uses which is binary
signature checking upon execution.

Another thing that I try to do as a better method of TPE which is a
breeze on OpenBSD and sometimes I find myself working against Linux
developers¹ is to make it so that any writeable area of the filesystem
is mounted noexec and mounts have the least priviledges required.


¹ "https://bugs.launchpad.net/ubuntu/+source/udisks/+bug/880965"
set as won't fix and also e.g. apt-get expecting /tmp exec.

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Matthew Finkel
On Sun, Dec 11, 2011 at 3:30 PM, Kevin Chadwick <[hidden email]> wrote:
On Sun, 11 Dec 2011 10:18:51 +0000
Sven Vermeulen wrote:

> Also consider hardening your system settings-wise. I would appreciate if you
> take a look at
> http://dev.gentoo.org/~swift/docs/previews/oval/gentoo-xccdf-guide.html.
> With the instructions given, you can even have your system validated (as far
> as possible) automatically.

I was expecting to find here what one distro uses which is binary
signature checking upon execution.

Another thing that I try to do as a better method of TPE which is a
breeze on OpenBSD and sometimes I find myself working against Linux
developers¹ is to make it so that any writeable area of the filesystem
is mounted noexec and mounts have the least priviledges required.

If don't mind my asking, what is it that OpenBSD does differently than the Linux distros that make it so much easier? Do they actually follow the security practices you mentioned in the bug report?

 

¹ "https://bugs.launchpad.net/ubuntu/+source/udisks/+bug/880965"
set as won't fix and also e.g. apt-get expecting /tmp exec.


Thanks, 
Matt

--
Matthew Finkel
Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

ma1l1ists
On Sun, 11 Dec 2011 18:00:19 -0500
Matthew Finkel <[hidden email]> wrote:

> > Another thing that I try to do as a better method of TPE which is a
> > breeze on OpenBSD and sometimes I find myself working against Linux
> > developers¹ is to make it so that any writeable area of the filesystem
> > is mounted noexec and mounts have the least priviledges required.
> >
>
> If don't mind my asking, what is it that OpenBSD does differently than the
> Linux distros that make it so much easier? Do they actually follow the
> security practices you mentioned in the bug report?
>
>
>
> >
> > ¹ "https://bugs.launchpad.net/ubuntu/+source/udisks/+bug/880965"
> > set as won't fix and also e.g. apt-get expecting /tmp exec.
> >
> >
> Thanks,
> Matt

Starting with the actual bug, on OpenBSD everything is off untill you
enable it like arch linux but their hotplugd allows you to easily edit
the commands and so mount options. Of course their are things like
devmon for Linux but the real issue was if a security policy tried to
stop introduction of executable code by users and then someone used the
install scripts and set up say ubuntu with udev by default then a user
could make a directory owned by root on an ext2 usb possibly name
it .exe and then execute their program violating the security policy
and possibly without the admins realising, it's that not caring about
security while developing that OpenBSD for obvious reasons (being it's
main goal) has. I guess it's akin to gentoo hardened fixing/preferring
their glibc and mozilla not making their binaries pax compatible

Also OpenBSD includes some userland which they audit
extensively. Packages use /usr/local and so you almost never need to
write to / or /usr, though package exploits and lack of developers may
force a move to current but for servers stable ports are generally kept
up to date. To get the best of both worlds (gentoo hardened too), you
could couple that ro mountability with grsecs in-kernel mount logging
and a secure logging facility but the linux kernel would make you
remount it a lot more often.

Generally they just think about these things, they won't for example
suddenly add an /opt and put insecure and often updated adobe-reader
into it, it would be /usr/local/opt if anything. Less rc scripts and in
one place. If someone tried to introduce xml to base OpenBSD they'd get
laughed at for trying to introduce an insecure technology. On Linux I
bet the people poking fun at xml would get laughed at for being absurd
even if xml isn't the best choice.

It's great and I love OpenBSD on my servers and especially firewalls
but it can be a bit much keeping firefox upto date on my desktops
(following current for firefox can mean no need to update for 9 months
or twice in two weeks, that would be fine if I had >100 desktops to
make a golden system worthwhile but I don't), and the firefox updates
can be quite late. It may? stop exploits affecting cross-boot but it's
a bit pointless having a secure desktop OS when firefox spends a week
out of date. RBAC also has more use for desktops with higher
exploitability. I looked to gentoo-hardened but unfortunately I can't
spend the build time or have the spare machines so I'm currently
looking at a grsec enabled arch possibly with a patched glibc as a
compromise with the aim of reducing maintenance time. I sure hope it
doesn't increase due to problems, it should reduce in theory atleast if
I stop writing this email ;-). As a bonus users will get sandboxed
flash.

Woah this is a long post and sorry if I'm relating debianisms too much,
I don't know gentoo-hardened that well and any insights/corrections
would be appreciated.

Kc

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Anthony G. Basile
In reply to this post by ma1l1ists
On 12/11/2011 03:08 PM, Kevin Chadwick wrote:

> On Sun, 11 Dec 2011 16:53:02 +0200
> Alex Efros wrote:
>
>> Hi!
>>
>> On Sun, Dec 11, 2011 at 02:25:19PM +0000, Sven Vermeulen wrote:
>>>> 1)  How can
>>>> 4.2.4.1. Root Logon Through SSH Is Not Allowed
>>>>     increase security, if we're already using
>>>> 4.2.4.2. Public Key Authentication Only
>>>>     Disabling root may have sense with password auth, but with keys it is
>>>>     just useless inconvenience.
>>>
>>> I read somewhere that security is about making things more inconvenient for
>>> malicious people than for authorized ones.
>>>
>>> For me, immediately logging in as root is not done. I want to limit root
>>> access through the regular accounts on the system (with su(do)). I never had
>>> the need to log on as root immediately myself.
>>
>> Understood. But I still don't see how this can increase security.
>>
>
> Defense in Depth, I disable root in >4 different ways.
>
> shell
> pam
> ssh_config
> securetty
> suid + setcap
> rbac
> chattr + immutable syscall turn off
>
> It may not help against root exploits but it makes life a little more
> difficult for priv escalation.
>
> It may take more work to iron out any diffciulties (short lived) but if
> you try to imagine the exploits rather than using minimal
> footprint/priviledges then you won't get that nice feeling of, hee hee
> doesn't affect me, nearly so often ;-). You'd be surprised, there's
> been lots of times where I've thought this is pointless and yet it's
> paid off eventually.
>

Do you have this documented anywhere.  It would be a good addition to
any system wide hardening docs we already have.

>
>>> 5)  In my experience, while
>>> 4.8.5. Review File Integrity Regularly
>>>   looks like good idea, it's nearly impossible to use in Gentoo because
>>>    of daily updates which change a lot of system files, so it's too hard
>>>    to review aide-like tool reports and quickly detect suspicious file
>>>    changes. If anyone have a good recipe how to work around this I'll be
>>>    glad to learn it.
>
>
> The king of this for full pc (x86 etc.) is OpenBSD, though package
> updates are more work. I have NEVER had to upgrade the kernel on an
> OpenBSD system due to security problems. (Only because I had disabled
> ipv6 where it wasn't needed though, which re-affirms the above. I would
> guess you would have said disabling ipv6 where it is not needed to be
> just a hindrance and not anything to do with security and yet it
> accounts for one of the only remote exploits on OpenBSD at default in
> more than a decade and meant that I could leave my systems humming away,
> rather than getting hot and bothered). In fact some of them could have
> been left untouched untill now if it wasn't for the want to upgrade.
>
> Of course an attacker who modifies files isn't very good these
> days. Though they are the ones you may catch.
>
> p.s. There really should be a central linux kernel security problem
> site as the work of necessarily good people seems duplicated at the
> moment?
>

Gentoo is not the only system with lots of daily updates.  I used to use
tripwire on RedHat boxes years ago and it was tedious sifting through
the files changes.  To construct good rules about what triggered an
alert just shifted the tedium.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : [hidden email]
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Anthony G. Basile-2
In reply to this post by ma1l1ists
On 12/11/2011 03:30 PM, Kevin Chadwick wrote:

> On Sun, 11 Dec 2011 10:18:51 +0000
> Sven Vermeulen wrote:
>
>> Also consider hardening your system settings-wise. I would appreciate if you
>> take a look at
>> http://dev.gentoo.org/~swift/docs/previews/oval/gentoo-xccdf-guide.html.
>> With the instructions given, you can even have your system validated (as far
>> as possible) automatically.
>
> I was expecting to find here what one distro uses which is binary
> signature checking upon execution.
>
> Another thing that I try to do as a better method of TPE which is a
> breeze on OpenBSD and sometimes I find myself working against Linux
> developers¹ is to make it so that any writeable area of the filesystem
> is mounted noexec and mounts have the least priviledges required.
>
>
> ¹ "https://bugs.launchpad.net/ubuntu/+source/udisks/+bug/880965"
> set as won't fix and also e.g. apt-get expecting /tmp exec.

How would you handle /etc/ ?  You can't separate it from / which needs
to be exec and yet /etc/ needs to be writeable.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

ma1l1ists
On Mon, 12 Dec 2011 06:59:30 -0500
"Anthony G. Basile" <[hidden email]> wrote:

> How would you handle /etc/ ?  You can't separate it from / which needs
> to be exec and yet /etc/ needs to be writeable.

What for after the main install, password changes (I use scripts
allowed via sudo for that and monitor mounts globally but the monitoring
could be improved like grsecs offering), some programs require it during
install but not many, none on my OpenBSD mail and web servers.

I'm in the process of attempting to complete this on Linux rather than
just /home etc. but on OpenBSD and the plan for single user linux
systems is to remount for updates, which is done in a controlled
fashion. Most of the time and especially on servers on OpenBSD you only
need to remount /usr/local. On those systems I use One Time Passwords
and if some rare thing means I do need to remount / then sudo allows
this, on others or on firewalls a reboot may be required if it's local
and redundant or if that's not a problem.

On OpenBSD desktops the only thing I did have to mount seperately was

/etc/X11/xdm/authdir

but I probably should have just made them single user/auto-login. Bigger
problems on OpenBSD servers (no devfs) are ttys for multi-user systems
or multiple ssh users needing tty permission changes, otherwise only
sftp works for all other users, which could be a feature for
me atleast ;-). Originally I was going to try mounting /dev seperately
but the book Absolute OpenBSD Unix for the practical paranoid said
you couldn't, I guess it would need to be built into the kernel to boot.

There's also secure knocking that runs commands that may not need ttys
but I think they have to be pre-ordained, but maybe not.

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

ma1l1ists
In reply to this post by Anthony G. Basile
On Mon, 12 Dec 2011 06:56:14 -0500
"Anthony G. Basile" wrote:

> Do you have this documented anywhere.  It would be a good addition to
> any system wide hardening docs we already have.

I'm afraid not, maybe sparsed among config file comments. I haven't
created a blog yet or any papers if that's what you mean. I haven't
really stopped for years. Hard to recall but I'll try to list them
somewhere as they come to me now. Another good example is suhosin php
command whitelisting which for small web-apps must avoid tons of
exploits of course that ones obviously not pointless.

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

ma1l1ists
On Mon, 12 Dec 2011 13:38:00 +0000
Kevin Chadwick wrote:

> Hard to recall but I'll try to list them
> somewhere as they come to me now.


Here's one example that's just come to me and that I configured but
never put in production. I acquired a free and supposedly good Cisco
router. I configured it and disabled the web server router
advertisements and all the other stuff it spits out by default that I
had no need for. Later an exploit in those very communications,
gratifying but no risk avoidance. Cisco have also had exploits in ipv6
and in other cheaper devices, default web root passwords etc..

Unless you need the performance I really wouldn't go near Cisco any
more. My cousin uses sonicwall, atleast one model uses assembly to speed
it up, which I'd look at in that case. Cisco's Senderbase use some dumb
mail reputation rules too, probably because I think it's a middle man
without the whole picture.

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Javier Juan Martinez Cabezon
About this:


> What for after the main install, password changes (I use scripts
> allowed via sudo for that and monitor mounts globally but the monitoring
> could be improved like grsecs offering), some programs require it during
> install but not many, none on my OpenBSD mail and web servers.


It's very bad idea to use sudo with scripts, in openbsd and everywhere. There are a lot of documentation about this question in the web.


> Another thing that I try to do as a better method of TPE which is a
> breeze on OpenBSD and sometimes I find myself working against Linux
> developersน is to make it so that any writeable area of the filesystem
> is mounted noexec and mounts have the least priviledges required.

The TPE in openbsd relies in the trustness of root, trusted is only feasible if nobody could reach root account (and daemons and suid binaries can still reach it in openbsd). Until openbsd doesn't implement mandatory controls and privilege separation (a.k.a posix capabilities) TPE will never be trusted under him .

Other problem is script interpretation, you don't need any exec mounted partition to launch a exploit, just a simple perl myhorribleexploit.pl does it.

In linux you can check under rbac if a script to get interpreted is trusted or not.


> I'm in the process of attempting to complete this on Linux rather than
> just /home etc. but on OpenBSD and the plan for single user linux
> systems is to remount for updates, which is done in a controlled
> fashion.

Again, What is exactly controlled fashion?. It gets never controlled because EXEC mount privilege is not needed to launch exploits and for this reason make TPE useless.

> but I probably should have just made them single user/auto-login. Bigger
> problems on OpenBSD servers (no devfs) are ttys for multi-user systems
> or multiple ssh users needing tty permission changes, otherwise only
> sftp works for all other users, which could be a feature for
> me atleast ;-). Originally I was going to try mounting /dev seperately
> but the book Absolute OpenBSD Unix for the practical paranoid said
> you couldn't, I guess it would need to be built into the kernel to boot.

> There's also secure knocking that runs commands that may not need ttys
> but I think they have to be pre-ordained, but maybe not.

If I remember correctly in openbsd exists too TIOCSTI and TIOCCONS ioctls, one allows root to send commands to user tty (hijacking) and the other one to spy it, how did you control under openbsd without mandatory controls?

> Starting with the actual bug, on OpenBSD everything is off untill you
> enable it like arch linux but their hotplugd allows you to easily edit
> the commands and so mount options. Of course their are things like
> devmon for Linux but the real issue was if a security policy tried to
> stop introduction of executable code by users and then someone used the
> install scripts and set up say ubuntu with udev by default then a user
> could make a directory owned by root on an ext2 usb possibly name
> it .exe and then execute their program violating the security policy
> and possibly without the admins realising, it's that not caring about
> security while developing that OpenBSD for obvious reasons (being it's
> main goal) has. I guess it's akin to gentoo hardened fixing/preferring
> their glibc and mozilla not making their binaries pax compatible

The bug in my opinion is rely into noexec mount option as a security option since you don't need it to launch untrusted code, just a perl/python interpreter is needed.
Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

ma1l1ists
On Mon, 12 Dec 2011 16:23:21 +0100
Javier Juan Martínez Cabezón wrote:

> > It's very bad idea to use sudo with scripts, in openbsd and everywhere.
> There are a lot of documentation about this question in the web.
>

Well actually that depends it is usually worse to run a script with sudo
but it can be worse to allow all commands within a script to be run by
sudo. I don't put /bin/sh script in sudoers and I am careful which
commands I put in sudoers. Please ellaborate.

>
> > Another thing that I try to do as a better method of TPE which is a
> > breeze on OpenBSD and sometimes I find myself working against Linux
> > developersน is to make it so that any writeable area of the filesystem
> > is mounted noexec and mounts have the least priviledges required.
>
> The TPE in openbsd relies in the trustness of root, trusted is only
> feasible if nobody could reach root account (and daemons and suid binaries
> can still reach it in openbsd). Until openbsd doesn't implement mandatory
> controls and privilege separation (a.k.a posix capabilities) TPE will never
> be trusted under him .
>

Actually I was talking about TPE in Linux not being potentially as
effective as noexec.
 
> Other problem is script interpretation, you don't need any exec mounted
> partition to launch a exploit, just a simple perl myhorribleexploit.pl does
> it.
>

You still can't execve and I believe noexec on Linux now prevents that?


> In linux you can check under rbac if a script to get interpreted is trusted
> or not.
>
>
> > I'm in the process of attempting to complete this on Linux rather than
> > just /home etc. but on OpenBSD and the plan for single user linux
> > systems is to remount for updates, which is done in a controlled
> > fashion.
>
> Again, What is exactly controlled fashion?. It gets never controlled
> because EXEC mount privilege is not needed to launch exploits and for this
> reason make TPE useless.
>

Environment and monitoring at the time of updates and no dangerous
actions like web browsing etc. etc. whilst the system is writable.

> > but I probably should have just made them single user/auto-login. Bigger
> > problems on OpenBSD servers (no devfs) are ttys for multi-user systems
> > or multiple ssh users needing tty permission changes, otherwise only
> > sftp works for all other users, which could be a feature for
> > me atleast ;-). Originally I was going to try mounting /dev seperately
> > but the book Absolute OpenBSD Unix for the practical paranoid said
> > you couldn't, I guess it would need to be built into the kernel to boot.
>
> > There's also secure knocking that runs commands that may not need ttys
> > but I think they have to be pre-ordained, but maybe not.
>
> If I remember correctly in openbsd exists too TIOCSTI and TIOCCONS ioctls,
> one allows root to send commands to user tty (hijacking) and the other one
> to spy it, how did you control under openbsd without mandatory controls?
>

An attacker is far less likely to get root on OpenBSD in the first
place but I am not trying to compare the two systems here. I could
reply with kernel attacks bypassing RBAC where execve would be
helpful but I don't want merits of the two being turned into one
of the many heated and pointless prevention versus protection debates.
We choose our poisons and the right cocktail for each application. I
also don't want to diverge so much from the ops original question which
may preclude OpenBSD?.


> > Starting with the actual bug, on OpenBSD everything is off untill you
> > enable it like arch linux but their hotplugd allows you to easily edit
> > the commands and so mount options. Of course their are things like
> > devmon for Linux but the real issue was if a security policy tried to
> > stop introduction of executable code by users and then someone used the
> > install scripts and set up say ubuntu with udev by default then a user
> > could make a directory owned by root on an ext2 usb possibly name
> > it .exe and then execute their program violating the security policy
> > and possibly without the admins realising, it's that not caring about
> > security while developing that OpenBSD for obvious reasons (being it's
> > main goal) has. I guess it's akin to gentoo hardened fixing/preferring
> > their glibc and mozilla not making their binaries pax compatible
>
> The bug in my opinion is rely into noexec mount option as a security option
> since you don't need it to launch untrusted code, just a perl/python
> interpreter is needed.

We disagree and if you look hard enough this was the reason the /tmp
bug was dismissed and has now been found to have been wrongfully
dismissed, you can't deny it hardens a system to some degree. It's quite
possible that you don't need to have perl or python installed. Though
OpenBSD does use perl quite extensively but also like hardening suid,
you could still restrict it's execution to groups. I'd also like to see
you run an unauthorised and buggy Windows program through perl that
could even listen to the network. (wine maybe authorised only for a set
task due to user or business demands)

Personally I see RBAC as a means of making it far more difficult to get
root. Once someone has root there is no way I'd rely on RBAC to defend
the memory, though we can always hope an attacker gives up on the extra
layer in our defences, which was the main point. More is better (DID).

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Javier Juan Martinez Cabezon
2011/12/12 Kevin Chadwick <[hidden email]>

>
> On Mon, 12 Dec 2011 16:23:21 +0100
> Javier Juan Martínez Cabezón wrote:
>
>
>
> Actually I was talking about TPE in Linux not being potentially as
> effective as noexec.
>
>
> You still can't execve and I believe noexec on Linux now prevents that?
>


I repeat, you don't need execve to launch untrusted code. When you do
"perl /tmp/somenastyscript", the script works even if you mounted as
noexec /tmp. This happens because the execve is only launch in
/bin/perl that "usually" has exec granted, in mynastyscript you only
just need read privileges granted in noexec.

None TPE without mandatory access control is effective, noexec is as
useless as TPE against script interpretation. The main difference is
that in linux you can implement a fully secure TPE, not under openbsd
since it lacks of rbac approachs.

Only a rbac can assure TPE restricting script interpretation as this:

perl execve ----->run under role perl.----->check-------- if script
marked trusted ----> change to user role and do what you have to do
                                                  --------> if script
untrusted (didn't mark as trusted)---> don't permit read and as result
don't make transition..

Since role perl has only read privileges against trusted scripts and
nothing else, TPE is secure because every untrusted code is prevented
from execution.

Under rsbac, execution is controlled under EXECUTE privilege with
execve and related calls and with MAP_EXEC for library mappings., TPE
is just a less approach under it because nothing has EXECUTE
privileges if they are not /bin /sbin or /lib directories is a result
of the less priviledge approach of rbac.

> Environment and monitoring at the time of updates and no dangerous
> actions like web browsing etc. etc. whilst the system is writable.

a bug in package software which privileges would grant to an attacker
with a crafted package exploiting a bug?, and if a privilege daemon is
running?

Your main problem is that you consider root trusted, and is not.

>
> An attacker is far less likely to get root on OpenBSD in the first
> place but I am not trying to compare the two systems here. I could
> reply with kernel attacks bypassing RBAC where execve would be
> helpful but I don't want merits of the two being turned into one
> of the many heated and pointless prevention versus protection debates.
> We choose our poisons and the right cocktail for each application. I
> also don't want to diverge so much from the ops original question which
> may preclude OpenBSD?.

who says that?, I'm sure that even with root account under my system
you don't get privileges at all, since root has not privileges. This
is the reason because a gnu/linux system could reach to B1 orange book
security level and openbsd to a simply C2, so linux can reach a
trusted status that openbsd no.

Openbsd only does a check, source code is full of if UID!=0 to everything.

It's a terrible error to think that openbsd has no errors, because
they have, it's wise to be prepared against bugs as MAC solutions
offers, it's of idiots to think that my software is perfect and free
of bugs and to think that they don't need MAC.


> We disagree and if you look hard enough this was the reason the /tmp
> bug was dismissed and has now been found to have been wrongfully
> dismissed, you can't deny it hardens a system to some degree. It's quite
> possible that you don't need to have perl or python installed. Though
> OpenBSD does use perl quite extensively but also like hardening suid,
> you could still restrict it's execution to groups. I'd also like to see
> you run an unauthorised and buggy Windows program through perl that
> could even listen to the network. (wine maybe authorised only for a set
> task due to user or business demands)
>
> Personally I see RBAC as a means of making it far more difficult to get
> root. Once someone has root there is no way I'd rely on RBAC to defend
> the memory, though we can always hope an attacker gives up on the extra
> layer in our defences, which was the main point. More is better (DID).
>
I repeat to you EXECUTE rights in a rbac system is granted just only
to /bin and /lib directories, none to /tmp. RBAC is sufficient to
avoid and confine this bug, you give me the reason because openbsd TPE
is useless, perl is present and uncontrolled as in "perl
/tmp/something". Try this it under openbsd with /tmp with noexec and
you will see that you can launch every script you want (without exec
calls but you dont need them to exploit vulnerabilities).

In rbac you can restrict PTRACE even to root, cap_sys_ptrace controls
it, PaX restricts the existence of PROT_EXEC PROT_WRITE simultaneously
in memory. Root under rbac neither can't mmap /dev/mem because he has
CAP_SYS_RAWIO removed, neither /dev/ports to I/O. Get realize that
root in rbac is not more than a simple user. Accessing to devices are
also fully controled and labeled according a B2 security level. If you
have modules interface they are controlled by CAP_SYS_MODULE that
could be revoked to root.

Suid to other uids are fully controlled, so nothing of suid(privuser)
to root. CAP_SYS_SUID check AND RBAC check, so both should be granted
to work.

Now please tell me how under this circunstances could root to make nothing.

12