[gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Tanstaafl]

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

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

On Sat, 10 Dec 2011 15:17:47 -0500
Tanstaafl <tanstaafl@libertytrek.org> 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)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-hardened] 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

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Alex Efros]

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.

Re: [gentoo-hardened] 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

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Alex Efros]

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.

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]

On Sun, 11 Dec 2011 16:53:02 +0200
Alex Efros <powerman@powerman.name> 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)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Hilco Wijbenga]

On 11 December 2011 06:53, Alex Efros <powerman@powerman.name> 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.

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Kevin Chadwick]

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?

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Kevin Chadwick]

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. 

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Matthew Finkel]

[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]

On Sun, Dec 11, 2011 at 3:30 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk>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

[-- Attachment #2: Type: text/html, Size: 1949 bytes --]

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Kevin Chadwick]

On Sun, 11 Dec 2011 18:00:19 -0500
Matthew Finkel <matthew.finkel@gmail.com> 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

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Anthony G. Basile]

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    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Anthony G. Basile]

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

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Kevin Chadwick]

On Mon, 12 Dec 2011 06:59:30 -0500
"Anthony G. Basile" <basile@opensource.dyc.edu> 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.

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Kevin Chadwick]

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.

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Kevin Chadwick]

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.

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Javier Juan Martínez Cabezón]

[-- Attachment #1: Type: text/plain, Size: 3631 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 4138 bytes --]

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Kevin Chadwick]

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).

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Javier Juan Martínez Cabezón]

2011/12/12 Kevin Chadwick <ma1l1ists@yahoo.co.uk>
>
> 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.

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Kevin Chadwick]

On Mon, 12 Dec 2011 18:38:28 +0100
Javier Juan Martínez Cabezón wrote:

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

What are you asking?

The heart of the OS is the kernel. The OpenBSD kernel is more secure
and always will be full stop because that is their main aim. Think about
the exploits in the Linux kernel for all those years whilst they were
present someone could have been exploiting them and still untill the
next one is added and/or found, one of them can likely bypass RBAC.
Restrictions upon root on OpenBSD have been shown to be bypassable
locally on Pentium >2s via cpu management mode by a root user, it's
still difficult. Therefore I try to use certain hardware and will still
use chflags sappnd etc..

Your example about execution can be controlled via file permissions, if
someone allows arbitrary running as root, RBAC or not that is dumb.
Your daemons should be chrooted as normal users so for servers rbac
means very little to me but I would use it if I ran Linux servers and
am planning to use it on my Linux desktops and OpenBSD would likely code
it if they had many more developers and got lots of the other stuff they
want done and couldn't find any more bugs. They certainly wouldn't
refuse a working and well written patch. For desktops or more
exploitable systems rbac gains some weight, so does systrace but all
these tools are good things (don't mention the races in systrace
because I'm not interested and it's still useful) and RAWIO is off by
default on OpenBSD.

Perl can only execute binaries on the system that are there and some
will on a large install contain local exploits or bugs which can be
reduced and fixed but not those introduced by users which could be far
more easily exploited and you can't even hope to prevent that. If you
can exploit the system through perl then that is a perl bug. If perl
scripts are a problem chmod it 750 and/or systrace it or rbac it. Next
you'll be telling me about physical security and bios batteries, well
physical security can exist and lets stop now as it is all irrelevent
and I'm sure everyone here is bored to death of the OpenBSD vs RBAC or
PAX topic.

All of this comes down to more is better and noexec mounts are one of
those blanket tools possibly with effective grsec logging. Exec logging
is usually too much to handle.

Also many exploits only do one particular thing, so dismissal like this
is simply wrong and part of the problem. In fact I remember Linux being
criticised for execution on downloads, the best answer was noexec should
be used. There is also the possibility of users loading up limewire
etc..

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Javier Juan Martínez Cabezón]

¿What can't you understand that you CAN translate one exploit in C in perl?

Are you joking? any user can write in their home directories their own
perl exploits. You can't restrict that. You can only restrict them
under rbac which scripts can be interpreted even for root, removing
execution to perl binary doesn't solve anything, because root can
still using it.

I think that you don't understand the term rbac, rbac removes root.
ROOT doesn't exists anymore.
Before talking what rbac does or not first read a bit what is it
because you don't understand it. Here you has info:

csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf

Comparing DAC with RBAC is simply stupid.

Daemons chrooted can still uploading untrusted code and get it
executed with posibility of privilege scalation even on root jail.

Telling me that you dont find sense of rbac in servers you told me
everything, this gives fine grained access controls, less privileges
approach without getting one full privilege approach for one part of
daemon (those permited to SUID to inner user in the daemon and to bind
to port < 1024 so before dropping)
With rbac a bug in the privilege code of a daemon doesn't grant access
to for example /etc/shadow it's confined, this does not happen
necessary under servers even under chroot.

 The openbsd kernel maybe more secure but read it is as horrible as to
read one economist reference book. I have never seen so many if UID
!=0 in so many different places in so many different functions as in
its kernel, maybe it's one of the lonely systems that read the source
code in assembler is easier even than read it in source C code.
Granularity is a word that openbsd developers seems to have forgotten
in their vocabulary and the word "comment the code" too.

Have you read it? or you have this idea about the goodeness about
their code because you read it in some web page?

Systrace is so dead that his hair is kilometers of long, when did they
do the last modification of their source code? in the 18th century?,
you confuse even too rbac with systrace, systrace is not an rbac it
just controls only which syscalls can a binary make, no granularity at
all.

Please repite with me: C exploits could be translated into perl. Any
user can write their own exploit in their home directory and with only
this sillyness execute it: scriptkiddie@hell:~$/bin/perl
./mysuidpreferedexploit.

 No need to execute privileges just only read one, users can know
howto write perl code. Users can use functions in perl or in python,
so users can do everything they want without getting execute priv and
only with a write permission to some directory (/tmp and
/home/hisdir). This can only be controlled with an RBAC approach
nothing more.

And not is not a bug perl, is using perl to write exploits they are
different questions.

2011/12/12 Kevin Chadwick <ma1l1ists@yahoo.co.uk>:
> On Mon, 12 Dec 2011 18:38:28 +0100
> Javier Juan Martínez Cabezón wrote:
>
>> Now please tell me how under this circunstances could root to make nothing.
>
> What are you asking?
>
> The heart of the OS is the kernel. The OpenBSD kernel is more secure
> and always will be full stop because that is their main aim. Think about
> the exploits in the Linux kernel for all those years whilst they were
> present someone could have been exploiting them and still untill the
> next one is added and/or found, one of them can likely bypass RBAC.
> Restrictions upon root on OpenBSD have been shown to be bypassable
> locally on Pentium >2s via cpu management mode by a root user, it's
> still difficult. Therefore I try to use certain hardware and will still
> use chflags sappnd etc..
>
> Your example about execution can be controlled via file permissions, if
> someone allows arbitrary running as root, RBAC or not that is dumb.
> Your daemons should be chrooted as normal users so for servers rbac
> means very little to me but I would use it if I ran Linux servers and
> am planning to use it on my Linux desktops and OpenBSD would likely code
> it if they had many more developers and got lots of the other stuff they
> want done and couldn't find any more bugs. They certainly wouldn't
> refuse a working and well written patch. For desktops or more
> exploitable systems rbac gains some weight, so does systrace but all
> these tools are good things (don't mention the races in systrace
> because I'm not interested and it's still useful) and RAWIO is off by
> default on OpenBSD.
>
> Perl can only execute binaries on the system that are there and some
> will on a large install contain local exploits or bugs which can be
> reduced and fixed but not those introduced by users which could be far
> more easily exploited and you can't even hope to prevent that. If you
> can exploit the system through perl then that is a perl bug. If perl
> scripts are a problem chmod it 750 and/or systrace it or rbac it. Next
> you'll be telling me about physical security and bios batteries, well
> physical security can exist and lets stop now as it is all irrelevent
> and I'm sure everyone here is bored to death of the OpenBSD vs RBAC or
> PAX topic.
>
> All of this comes down to more is better and noexec mounts are one of
> those blanket tools possibly with effective grsec logging. Exec logging
> is usually too much to handle.
>
> Also many exploits only do one particular thing, so dismissal like this
> is simply wrong and part of the problem. In fact I remember Linux being
> criticised for execution on downloads, the best answer was noexec should
> be used. There is also the possibility of users loading up limewire
> etc..
>

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Kevin Chadwick]

On Mon, 12 Dec 2011 20:44:37 +0100
Javier Juan Martínez Cabezón wrote:

> ¿What can't you understand that you CAN translate one exploit in C in perl?
> 
> Are you joking? any user can write in their home directories their own
> perl exploits. You can't restrict that. 


You know you can. No perl binary, or chmod 750 or rbac as I had said.
All exploits are bugs and it should be harder to escalate priviledges
through perl than by introducing your own C.


> You can only restrict them
> under rbac which scripts can be interpreted even for root, removing
> execution to perl binary doesn't solve anything, because root can
> still using it.
> 

You are simplifying everything, security is a process. Noexec is a
useful tool. How much of what I said did you read. I understand your
points and most security has nothing to do with root. I understand root
can execute files chmodded 000 and I agree that RBAC is useful, the
point is so is noexec and systrace.


> I think that you don't understand the term rbac, rbac removes root.
> ROOT doesn't exists anymore.
> Before talking what rbac does or not first read a bit what is it
> because you don't understand it. Here you has info:

No it doesn't it restricts root. An exploit may bypass RBAC it may
bypass mount restrictions it may bypass both it may only bypass one, in
which case they are both again useful.

And OpenBSDs systrace can restrict a lot. System calls are the
hearts heart of an OS.

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Javier Juan Martínez Cabezón]

> You know you can. No perl binary, or chmod 750 or rbac as I had said.
> All exploits are bugs and it should be harder to escalate priviledges
> through perl than by introducing your own C.

Clear, making use intensive under openbsd as you said. With 750 even
with 700 root can stills using it, as in extension any software run by
him. It's harder programming in python than in C? in python you can
write exploits too, no it isn't harder. Any programmer can do it.

> You are simplifying everything, security is a process. Noexec is a
> useful tool. How much of what I said did you read. I understand your
> points and most security has nothing to do with root. I understand root
> can execute files chmodded 000 and I agree that RBAC is useful, the
> point is so is noexec and systrace.

Noexec is not usefull at all I give you the reason it does not
controls scripts interpretation is a false sense of security. Is
something like get a not executable stack without pax mprotect, it
does nothing alone

My system has no root, root has all capabilities in 0, so the same
privileges as a normal user has, can't do ptrace to others process,
can't read files not our, can't load modules etc etc etc. Every
capability is removed. Check rsbac.org. With rbac even root can't
access a program he has started. Read about rbac and when you get
understood which it offers then told me what it can or what does not
offers.

Systrace is dead, the project is dead. It does not exists from long ago.
>
> No it doesn't it restricts root. An exploit may bypass RBAC it may
> bypass mount restrictions it may bypass both it may only bypass one, in
> which case they are both again useful.
>
> And OpenBSDs systrace can restrict a lot. System calls are the
> hearts heart of an OS.

I have said to you that rbac can make impossible to launch untrusted
code (even exploits) executed and interpreted as in perl myperlscript.
In one of my first mail I pointed you ways in that root can do harm
and how rbac can avoid them. Root is not important because root is
only important in DAC not in RBAC. Read the link I sen't to you before
because you stills not understood this point.

Yes an system dead long ago, and not it only do this: after this bind
you can only get a listen. It gives not flexibility, granularity at
all.

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Kevin Chadwick]

On Mon, 12 Dec 2011 22:04:30 +0100
Javier Juan Martínez Cabezón wrote:

> 
> Noexec is not usefull at all I give you the reason it does not
> controls scripts interpretation is a false sense of security. Is
> something like get a not executable stack without pax mprotect, it
> does nothing alone
> 

It is an extra security measure for defense in depth.

It allows easy use and a better default widely understood and
blanket setting that almost any user can understand and switch off and
so is more likely (not very) to be applied across the board.

It gives admins extra control.

Shall we get rid of file permissions because we have RBAC. We could
but I can't see that happening and for good reason.

Who said it was lonely :)

> My system has no root, root has all capabilities in 0, so the same
> privileges as a normal user has, can't do ptrace to others process,
> can't read files not our, can't load modules etc etc etc. Every
> capability is removed. Check rsbac.org. With rbac even root can't
> access a program he has started. Read about rbac and when you get
> understood which it offers then told me what it can or what does not
> offers.
> 

I do and I disagree here though we are both right really as has been
the case for most of this discussion. RBAC can restrict root and
root has the potential to make Direct attacks on the kernel via the
memory, accessible devices and perhaps even RBAC itself. Things do
require priviledges and RBAC reduces those granted and is good but if
RBAC removed root the kernel wouldn't be able to turn on and off RBAC
and the boot phase wouldn't be vulnerable. I already realised that RBACs
were path and Role based, some inode based and probably many other
flavours. I looked over that pdf but I do have far better ones that
don't belittle systrace like you do.

> Systrace is dead, the project is dead. It does not exists from long ago.

> >
> > No it doesn't it restricts root. An exploit may bypass RBAC it may
> > bypass mount restrictions it may bypass both it may only bypass one, in
> > which case they are both again useful.
> >
> > And OpenBSDs systrace can restrict a lot. System calls are the
> > hearts heart of an OS.
> 
> I have said to you that rbac can make impossible to launch untrusted
> code (even exploits) executed and interpreted as in perl myperlscript.
> In one of my first mail I pointed you ways in that root can do harm
> and how rbac can avoid them. Root is not important because root is
> only important in DAC not in RBAC. Read the link I sen't to you before
> because you stills not understood this point.
> 

I knew this

> Yes an system dead long ago, and not it only do this: after this bind
> you can only get a listen. It gives not flexibility, granularity at
> all.


Admittedly systrace doesn't get much attention but then it does what it
says on the tin and how about Aug 2011.

http://marc.info/?l=openbsd-tech&m=131484069706394&w=2

This pdf is a bit old (2005) but it actually says the problem with
systrace is that it is so fine grained it is hard to setup well.

"http://z.cliffe.schreuders.org/publications/Honours%20Thesis.pdf"


Lets make this constructive. Maybe you can tell me which RBAC you use
and why you chose it.

Thanks

Kc

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Javier Juan Martínez Cabezón]

> It is an extra security measure for defense in depth.
>
> It allows easy use and a better default widely understood and
> blanket setting that almost any user can understand and switch off and
> so is more likely (not very) to be applied across the board.
>
> It gives admins extra control.
>

A inefficient and useless layer if not complemented with extra measures.

> Shall we get rid of file permissions because we have RBAC. We could
> but I can't see that happening and for good reason.

file permissions are discrectional, rbac mostly mandatory, don't try
to compare them.


> I do and I disagree here though we are both right really as has been
> the case for most of this discussion. RBAC can restrict root and
> root has the potential to make Direct attacks on the kernel via the
> memory, accessible devices and perhaps even RBAC itself. Things do
> require priviledges and RBAC reduces those granted and is good but if
> RBAC removed root the kernel wouldn't be able to turn on and off RBAC
> and the boot phase wouldn't be vulnerable. I already realised that RBACs
> were path and Role based, some inode based and probably many other
> flavours. I looked over that pdf but I do have far better ones that
> don't belittle systrace like you do.

It does not restrict root, it erase it. The concept of root doesn't
exists anymore.
Give me an example of direct attack via memory as you say, accessible
devices and anything else said you before.

Raw access is fully controlled and forbidden to root, raw access to
ttys and block devices too, controlled the mount of devices etc etc
etc

You don't know what rbac is so don't speak about it because you can't
understand it


>
> Lets make this constructive. Maybe you can tell me which RBAC you use
> and why you chose it.
>
> Thanks
>
> Kc
>
I use rsbac as framework, with modules RC, ACL, exclusive UM, RES,
JAIL, MAC, PAX, AUTH and CAP running.

Root has not capabilities, not CAP_SYS_RAWIO, no DAC_OVERRIDE, not
SYS_MODULES etc etc he can only execute binaries in /sbin and /bin,
map /lib libraries and nothing else, halt has its own role and type,
so root even can't switch down the machine for example. Master role of
sshd even has more privileges than root itself.

I use rsbac because it reachs to B1 security level, level that openbsd
will never reach, it supports even secure_delete, and has some B2
charateristics as device labels are.

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Peter Volkov]

В Вск, 11/12/2011 в 16:53 +0200, Alex Efros пишет:
> 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.

To authorize you need pair: login/password or login/priv_key. By
requiring login be guessable too you make probability to guess both
harder. Remember how debian  made possible to brute-force private
key[1]? Additional layers really may help in some situations...


1. http://digitaloffense.net/tools/debian-openssl/

--
Peter.

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Peter Volkov]

В Вск, 11/12/2011 в 16:53 +0200, Alex Efros пишет:
> 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.

To authorize you need pair: login/password or login/priv_key. By
requiring login be guessable too you make probability to guess both
harder. Remember how debian  made possible to brute-force private
key[1]? Additional layers really may help in some situations...


1. http://digitaloffense.net/tools/debian-openssl/

--
Peter.

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Kevin Chadwick]

On Tue, 13 Dec 2011 22:20:00 +0100
Javier Juan Martínez Cabezón wrote:

> Give me an example of direct attack via memory as you say, accessible
> devices and anything else said you before.

I suggest you do some more reading at grsecurity.net or even the
OpenBSD mailing list. I haven't got time to hunt down the two references
that stick in my mind but keep your ears open and you may realise one
of the kernel exploits could/can/will do just that. Do you really
believe it's impossible??!!


>> Shall we get rid of file permissions because we have RBAC. We could
>> but I can't see that happening and for good reason.

> file permissions are discrectional, rbac mostly mandatory

I have no idea what you are arguing with, you just keep trying to twist
what I say because you have a bee in your bonnet about MACs as the
answer to everything and a panacea, they aren't but they are useful as I
have said. Personally I wouldn't swap an OpenBSD kernel for the Linux
one with RBAC on my servers atleast. One day with a risky setup, I
might in that instance. I wonder why kernel.org didn't use RBACs,
especially RSBAC or even chroot. How embarrassing for such an automated
attack to get through. Is bugzilla.kernel.org still down? That wouldn't
have happened if they were using OpenBSD. It might be a good idea to use
a different kernel to the one they are hosting anyway even with many
eyes. And before you think well this is just me clutching at straws with
your tunnel vision, it relates exactly to what I was talking about
of likelihood of use.

>> don't try to compare them.

Of course you should and I was saying much of RBACs can be replaced and
you use both and it adds to defence in depth. Your notion of replacing
DACs? I see good and bad in that.


>> It does not restrict root, it erase it. The concept of root doesn't
>> exists anymore.

What is root, it is the root of the system not just a user. If it
didn't exist the kernel wouldn't be able to turn RBAC off now would it.
You have been drawn in by the wonderful marketing of imagine a system
where root doesn't exist. Would your analogy be the kernel recreates
root. If so, fine it makes no difference but is less correct.


> I use rsbac because it reachs to B1 security level, level that openbsd
> will never reach, it supports even secure_delete, and has some B2
> charateristics as device labels are.


And yet your kernel has bugs added every day without much security
consideration. What you don't understand is that RBAC is a security
layer that the root of the system has control of. What can
your /sbin/init do, what can the kernel do? Some rootkits can actually
go the other side of the kernel even, far above where RBACs are.

Yeah and Cisco's are certified for use by some enterprise manager and
yet they have proven full of root exploits. Certified encryptions are
often less secure than others.

I repeat it ALL depends on the application, even the hardware. You
could reduce the Linux kernel right down to protect the RBAC. Which
was my original point.

Of course then I wonder if the RBAC would actually ever be needed but
it's ALL GOOD.

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Javier Juan Martínez Cabezón]

> I suggest you do some more reading at grsecurity.net or even the
> OpenBSD mailing list. I haven't got time to hunt down the two references
> that stick in my mind but keep your ears open and you may realise one
> of the kernel exploits could/can/will do just that. Do you really
> believe it's impossible??!!
>
I give you proofs because  the arguments you defend are wrong, give
proofs about the oposite if you can.

I told you, with a secure TPE (so scripts fully controlled) tell me
how to write one kernel exploit under bash without calling external
code.


>>> Shall we get rid of file permissions because we have RBAC. We could
>>> but I can't see that happening and for good reason.
>
>> file permissions are discrectional, rbac mostly mandatory
>
> I have no idea what you are arguing with, you just keep trying to twist
> what I say because you have a bee in your bonnet about MACs as the
> answer to everything and a panacea, they aren't but they are useful as I
> have said. Personally I wouldn't swap an OpenBSD kernel for the Linux
> one with RBAC on my servers atleast. One day with a risky setup, I
> might in that instance. I wonder why kernel.org didn't use RBACs,
> especially RSBAC or even chroot. How embarrassing for such an automated
> attack to get through. Is bugzilla.kernel.org still down? That wouldn't
> have happened if they were using OpenBSD. It might be a good idea to use
> a different kernel to the one they are hosting anyway even with many
> eyes. And before you think well this is just me clutching at straws with
> your tunnel vision, it relates exactly to what I was talking about
> of likelihood of use.

I have never said to eliminate DAC. I just told that ONLY DAC as
openbsd do is a bad option and insecure.
You can substitute DAC with RBAC (and RSBAC gives an option to do it).

Now DAC and RBAC are layered, RBAC can be secure without DAC, DAC
WOULD NEVER be secure without RBAC.


> What is root, it is the root of the system not just a user. If it
> didn't exist the kernel wouldn't be able to turn RBAC off now would it.
> You have been drawn in by the wonderful marketing of imagine a system
> where root doesn't exist. Would your analogy be the kernel recreates
> root. If so, fine it makes no difference but is less correct.

I repeat you (and get your ears cleaned) UID 0 is only relevant UNDER
DAC approach.

RBAC doesn't use UIDS just roles read about rbac AGAIN. And UID 0
under rbac can do NOTHING. UID 0 can't switch off nothing only role
admin can do it, and usually is not UID 0, in rsbac is UID 400.

Some binaries with independency of which user executes it, change to
their own role and can do ONLY which his role can do., for example my
syslog-ng role when executed can only access in append mode to logs
files and mapping libraries under /lib, can just access to /dev/log. A
exploit ran against syslog will NOT GET full control over the system
even when ran under root account without dropping just to what his
role can do.

Root in a DAC can do which it does because the capabilities, in my
system (I told you again) root has not capabilities, is just a simple
user.

As you can suppose this user 400 doesn't launch daemons (neither init)
and run any software he just administrate the policy, and nobody can
suid to his uid without getting authenticated (password) against UM
module, so there is not way to get suid to his account in a exploit
approach.

I told you many times that TPE under proper RBAC is secure, because
only a bash script without calling extern code could be launched as an
exploit, so it's nearly impossible to do it. Write me a bash script
kernel exploit if you can.

Even with that this role admin or authority could be fixed forever
just revoking to his role these privileges.


> And yet your kernel has bugs added every day without much security
> consideration. What you don't understand is that RBAC is a security
> layer that the root of the system has control of. What can
> your /sbin/init do, what can the kernel do? Some rootkits can actually
> go the other side of the kernel even, far above where RBACs are.

Read the orange book, this is the question because mandatory access
controls exists to confinate damage and avoid them. My init can't suid
to secoff UID, and he can't only call scripts and nothing more. Getty
runs with his own role, scripts with their own, login with it's own
and init with it's own. ROOT DOES NOT CONTROL RBAC, RBAC controls him.

There is no way that a rootkit could access to kernel memory,
/dev/mem, ioports an alike devices are fully controlled and module
interfaz too and kernel sources too. Tell me how the hell can anyone
launch a ring 0 rootkit, and give proofs as I did a not simple search
in grsec or openbsd sites.


> I repeat it ALL depends on the application, even the hardware. You
> could reduce the Linux kernel right down to protect the RBAC. Which
> was my original point.
>
RBAC IS the kernel, is the PCB. The PCB protects himself from
userland, and root is part of this userland, and for this reason root
has not rights over it, it has them over him. By this reason the
access control is mandatory.

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Alex Efros]

Hi!

On Wed, Dec 14, 2011 at 04:27:45PM +0100, Javier Juan Martínez Cabezón wrote:
> I told you, with a secure TPE (so scripts fully controlled) tell me
> how to write one kernel exploit under bash without calling external
> code.

How about
    $ perl -e 'exploit code here'
or just
    $ perl
    exploit code here from stdin
    Ctrl-D
?
Is your current RBAC configuration prevent this?

As for me, I tend to agree with you about RBAC, but I think to make RBAC
really useful it rules/roles must be provided by software developers -
just like they now provide README and Makefile, because only software
authors actually know which files, devices and syscalls used by their
applications and how these requirements change from version to version.

I've tried different RBAC implementations few times, but got tired fixing
roles and rules - on usual hardened workstation after enabling RBAC (even
after auto-learning mode) everything become broken in many unexpected
ways, and it took too many time to realize each time this isn't a bug in
some software but just RBAC misconfiguration and fixing it. Probably
workstation isn't good place for RBAC. But on most of my servers there are
a lot of perl scripts, and we often add new scripts, and writing RBAC
rules for all of them looks too complicated. Another server must have php,
ftp, many wordpress sites and other php crap - and I can't even imagine
how this can be secured using RBAC.

BTW, while I agree with you about useless 'noexec' for /tmp, it's usually
cheap way to stop few scriptkiddies with default exploits, so there is no
harm in using it. And no real harm in don't using it.

-- 
			WBR, Alex.

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Javier Juan Martínez Cabezón]

when perl is executed as interpretation (perl mynastyscript) it
changes his role to perl_role

perl role has only the rights to open scripts marked as trusted, if
the script is trusted, read is permitted and a change of role happens
to user role is done. If it's not trusted, then perl can only do what
perl_r do (mapping standard libraries), perl_r can map libperl.so, it
can write the code this library permits. He shall rewrite the wheel
too many times.

Maybe I could make checks forbidding this library mapping and granting
only when transition is done (so when is clear that the script is
trusted). I shall check it.


2011/12/14 Alex Efros <powerman@powerman.name>:
> Hi!
>
> On Wed, Dec 14, 2011 at 04:27:45PM +0100, Javier Juan Martínez Cabezón wrote:
>> I told you, with a secure TPE (so scripts fully controlled) tell me
>> how to write one kernel exploit under bash without calling external
>> code.
>
> How about
>    $ perl -e 'exploit code here'
> or just
>    $ perl
>    exploit code here from stdin
>    Ctrl-D
> ?
> Is your current RBAC configuration prevent this?
>
> As for me, I tend to agree with you about RBAC, but I think to make RBAC
> really useful it rules/roles must be provided by software developers -
> just like they now provide README and Makefile, because only software
> authors actually know which files, devices and syscalls used by their
> applications and how these requirements change from version to version.
>
> I've tried different RBAC implementations few times, but got tired fixing
> roles and rules - on usual hardened workstation after enabling RBAC (even
> after auto-learning mode) everything become broken in many unexpected
> ways, and it took too many time to realize each time this isn't a bug in
> some software but just RBAC misconfiguration and fixing it. Probably
> workstation isn't good place for RBAC. But on most of my servers there are
> a lot of perl scripts, and we often add new scripts, and writing RBAC
> rules for all of them looks too complicated. Another server must have php,
> ftp, many wordpress sites and other php crap - and I can't even imagine
> how this can be secured using RBAC.
>
> BTW, while I agree with you about useless 'noexec' for /tmp, it's usually
> cheap way to stop few scriptkiddies with default exploits, so there is no
> harm in using it. And no real harm in don't using it.
>
> --
>                        WBR, Alex.
>

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Kevin Chadwick]

On Wed, 14 Dec 2011 16:27:45 +0100
Javier Juan Martínez Cabezón wrote:

When I have more time I promise to hunt the references out and send
them to you.

> I have never said to eliminate DAC. I just told that ONLY DAC as
> openbsd do is a bad option and insecure.
> You can substitute DAC with RBAC (and RSBAC gives an option to do it).
> 
> Now DAC and RBAC are layered, RBAC can be secure without DAC, DAC
> WOULD NEVER be secure without RBAC.

Let's play your game as you keep mixing up contexts and you're the one
making blanket statements not me and telling me you know what I know
better than myself. I merely said that methods of breaking RBAC have
been discussed and a kernel exploit is one of them.

So show me how you can break out of the default apache on OpenBSD then?

>> There is no way that a rootkit could access to kernel memory,
>> /dev/mem, ioports an alike devices are fully controlled and module
>> interfaz too and kernel sources too. Tell me how the hell can anyone
>> launch a ring 0 rootkit, and give proofs as I did a not simple search
>> in grsec or openbsd sites.

>> RBAC IS the kernel,
>>

RBAC is part of the kernel yes and so stored in memory. It is also a
part of the kernel that is meant to be switchable. An exploit in the
kernel can not only bypass RBAC or switch it off it can even situate a
rootkit above the kernel leaving RBAC in place and having ALL rights
aka the root of the system. Yes a perfect policy may prevent an exploit
but it's equally possible that a perfect policy has to allow the
exploit for desired functionality.

The question is what is more important, keeping attackers out or making
sure your policies are good enough to stop them. I prefer OpenBSD for
many reasons aside from just this anyway.

You turned this into a bashing of OpenBSD and I'm not sure anyone here
appreciates the hijacking of this thread, I should have known better
than to mention OpenBSD here and almost removed it before sending, lets
stop and agree to disagree. It's not the first time the importance of
RBACs bug exploitation prevention versus bug removal and prevention at
source has been discussed. Hopefully one day the Linux kernel will be
as bug free and capable to be safely as static as OpenBSDs, I also hope
OpenBSD gets a MAC one day too. Unfortunately I can't see either
happening.

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Javier Juan Martínez Cabezón]

[-- Attachment #1: Type: text/plain, Size: 3837 bytes --]

Let's play your game as you keep mixing up contexts and you're the one
> making blanket statements not me and telling me you know what I know
> better than myself. I merely said that methods of breaking RBAC have
> been discussed and a kernel exploit is one of them.
>
> I haven't seen no methods in your mails of breaking nothing, only search
in the web ones.


> So show me how you can break out of the default apache on OpenBSD then?
>

With a bug in the portion of code with privileges. But it's not needed, any
bug in any software (as ports that are not audited) that gets root in
openbsd can kill apache process, but yeah it's clear that is nearly
impossible to get a remote hole in coreutils because they audit his
code.....



>
>
> RBAC is part of the kernel yes and so stored in memory. It is also a
> part of the kernel that is meant to be switchable. An exploit in the
> kernel can not only bypass RBAC or switch it off it can even situate a
> rootkit above the kernel leaving RBAC in place and having ALL rights
> aka the root of the system. Yes a perfect policy may prevent an exploit
> but it's equally possible that a perfect policy has to allow the
> exploit for desired functionality.
>
> What do you think that grsec and rsbac is SELinux alike?, Brad Spender
prove that selinux could be disabled because his stupid architecture of LSM
with exported symbols, grsec and rsbac doesn't work at the horrible way
that selinux does and has every code in main code everywhere, there is not
a magic button "switch_off" as SELINUX.  Grsec and Rsbac are not a part of
the kernel are the kernel itself. In rsbac every syscalls are intercepted,
any open(O_RDLY) calls done is intercepted and "substitute" by an READ_OPEN
request that should be granted to work, the portion of code that has open
calls has the rsbac calls ones there.

Can you patch the kernel on the fly without accessing devices? or without
modules interface? or without using ioports interface? just using syscall
interface? prove it, but don't get surprised if you get your funny process
killed because trying ring 0 changes from ring 3 is strictly forbidden
through it, supervisor mode is called I think...

If you can do it you can do then drivers from userspace without glue kernel
layer as fuse does (yes in your information is needed a kernel interface to
make it work, you can't do directly ring 0 interfaces with only userspace
code...


The question is what is more important, keeping attackers out or making
> sure your policies are good enough to stop them. I prefer OpenBSD for
> many reasons aside from just this anyway.
>
> At first sight it seems that you only want to make publicy of openbsd in a
gentoo hardened mailing list in a thread of a user that asks explicetly to
suggestions about it, at least with my answers he could check rbac data and
could save something from them. With yours answers I don't know what can he
take in clear.

You turned this into a bashing of OpenBSD and I'm not sure anyone here
> appreciates the hijacking of this thread, I should have known better
> than to mention OpenBSD here and almost removed it before sending, lets
> stop and agree to disagree. It's not the first time the importance of
> RBACs bug exploitation prevention versus bug removal and prevention at
> source has been discussed. Hopefully one day the Linux kernel will be
> as bug free and capable to be safely as static as OpenBSDs, I also hope
> OpenBSD gets a MAC one day too. Unfortunately I can't see either
> happening.
>

I only correct your mistakes and try to avoid that the user gets confused
by you,
I have been all the thread showing that you noexec implemention does not
work and exposed the reason about this and probable solutions. If you are
blind about this don't try to extend your blindness to the user that wants
suggestions.

[-- Attachment #2: Type: text/html, Size: 4848 bytes --]

Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Kevin Chadwick]

Javier Juan Martínez Cabezón wrote:

> there is not
> a magic button "switch_off" as SELINUX.

and yet previously

>> UID 0 can't switch off nothing only role admin can do it, and usually
>> is not UID 0, in rsbac is UID 400.

>> DAC WOULD NEVER be secure without RBAC.

and yet this is DAC with chroot

> but yeah it's clear that is nearly
> impossible to get a remote hole in coreutils because they audit his
> code.....

> I only correct your mistakes and try to avoid that the user gets
> confused by you,
> I have been all the thread showing that you noexec implemention does not
> work and exposed the reason about this and probable solutions. If you
> are blind about this don't try to extend your blindness to the user
> that wants suggestions.

It is dismissive people like you giving excuses to developers to lower
the default security of Linux for all those desktops who can't spend
time on security and for which noexec would and could have prevented
exploits from downloads to the home directory and from usbs and so udev
potentially violating companies policies of users not running arbitrary
windows programs.

I certainly can't see an end user editing selinux or rsbac and a small
chance of apparmor or rbac in order to run Enemy Territory Quake Wars
or whatever "backlash" reverted noexec from the default mount options.

noexec could have immediately quashed the rubbish like "linux is
vulnerable to viruses too" publicity when the ld.so bug was found,
potentially keeping some on windows.

noexec is not useless and I maintain that arbitrary C code is far more
dangerous than perl or shell. It would also be rediculously easy
for script interpreters to check for noexec and die, heck a wrapper that
checked and changed the egid then allowing perl execution could do it.

"Maybe it is pointless because of usbonthego and all the past bugs in
the usb code upon insertions" (sarcasm)

It is no coincidence that most successful attacks come from phishing
and duplicated passwords. A far cry from RSBAC.

If anyone is misleading anyone, it is you. OpenBSD works for
itself (developers), it does not care even about it's users, if I was
trying to get people to use it, I would and could have come up with
chapters, in fact I stopped myself and have again now. I wouldn't do
that, I don't have time to do that and respect the gentoo hardened
community, the only things I have mentioned are ones that I would like
Linux developers to take note of such as bug reduction in the Linux
kernel and making it easier to track them. OpenBSD is a big part of my
life and so it is bound to slip out when offering advice.

Have you ever disabled ipv6? We could certainly do with ipv5 (just more
addresses)

As you seem to have spent time developing your RSBAC policies and if
you have spent time with grsecs rbac. I would be interested in what you
see makes rsbac worth that extra time over grsec rbac and any good
documents for using them. It seems to me that rsbac is more robust but
takes more time to develop the policies.

Kc