Re: What are the security features in OpenBSD 6.0 that are by default disabled?

[Otto Moerbeek]

On Sun, Oct 16, 2016 at 07:10:54PM -0500, Patrick Dohman wrote:

> 
> > nonsense. daily security is mailed *if it is non-empty*. Same goes for
> > weekly and mothly.
> > 
> > -Otto
> 
> i guess that’s explains why the output of who was omitted from the insecurity 
> out

either be specific, provide details of what you
are seeing or stop sending useless mails.

-Otto

Re: What are the security features in OpenBSD 6.0 that are by default disabled?

[Aaron Mason]

There needs to be a new law like Godwin's Law that states that any
technical discussion will eventually and inevitably lead to
Hitchhiker's Guide references.

But to follow on from what Raul said, it may be impossible to make
your system 100% secure without violating part 15 of the FCC rules,
probably along with several other parts.

On Sun, Oct 16, 2016 at 8:32 AM,   wrote:
> On Fri, 14 Oct 2016 20:50:20 +0200
> "thrph.i...@gmail.com"  wrote:
>
>> or this kind...
>>
>> " The only truly secure system is one that is powered off, cast in a
>> block of concrete and sealed in a lead-lined room with armed guards -
>> and even then I have my doubts. "
>>
>
> It needs to be stored under a filing cabinet in a disused lavatory with
> a sign on the door saying Beware of the Leopard.
>



-- 
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse

Re: What are the security features in OpenBSD 6.0 that are by default disabled?

[Patrick Dohman]

> nonsense. daily security is mailed *if it is non-empty*. Same goes for
> weekly and mothly.
>
>   -Otto

i guess that’s explains why the output of who was omitted from the
insecurity out

Re: What are the security features in OpenBSD 6.0 that are by default disabled?

[Peter Janos]

use S for extras security at the expense of performance. Use other options
only if you know what you are doing and have specific needs.
BTW, ssh and sshd enable S by themselves.
 
-Otto

 
-> so "S" is the best way, Thanks! :)
 
Sent: Friday, October 14, 2016 at 12:20 PM

From: "Otto Moerbeek" 
To: "Peter Janos" 
Cc: "openbsd misc" 
Subject: Re: What are the security features in OpenBSD 6.0 that are by
default disabled?
On Fri, Oct 14, 2016 at 09:21:24AM +0200, Peter Janos wrote:

> Hello,
>
> I know some features that can give additional security isn't turned on due
to
> because of the bad quality of the code in ports and some also decreases
> performance (or disables a feature, ex.: screenlock doesn't work if nosuid
> set, but if feature not used, nousid can be used).
>
> I only know about these "security hardenings", hopefully all are ok (if
not,
> please say/argue!):
>  
> ==
> ln -s GJU /etc/malloc.conf

$ man man.conf | grep security

-Otto
 

Fw: RE: RE: OpenBSD PaX Test question

[Peter Janos]

if anyone interested, correction for the pax topic Sent: Tuesday, October
11, 2016 at 3:57 PM
From: "W. Dean Freeman" 
To: "'Peter Janos'" 
Subject: RE: RE: OpenBSD PaX Test questionIncreasing the stack gap size
isn't necessarily bad or good. Basically,
you're adjusting the run-time value of a gap page that gets inserted at
the
top of a new stack frame, so that when an attacker is analyzing a binary
and
attempting to write an exploit, there is an unknown-at-compile-time
number of
bytes which have to be included when building the exploit and attempting
to
over-write the return address to the previous stack frame. It's just one
of a
series of mitigations against buffer overflows (like stack canaries, W^X,
etc.
You're also here adjusting the amount of room there is to play with when
randomzing addresses for ASLR, at least as is my understanding.

So, I doubt it hurts anything, but given the general strength of ASLR,
stack
gaps, stack cookies, the new W^X feature, etc. I'm not sure it's really
necessary. If you really want to play with something fun that may ferret
out
bugs either in your code or in things you get from ports, turn on memory
junking in the /etc/malloc.conf. For a discussion on some fun around
that,
see here:

https://www.youtube.com/watch?v=YYf1U0xcHmk

To the second question, there isn't any magic to what I'm doing in that
program and between screenshots from GDB and a description of what's
going on,
you should be able to reconstruct it. There are three basic tests:
1. Attempt to mmap(2) a page of memory with permissions
PROT_WRITE|PROT_EXEC
** on OpenBSD, this will cause the program to abort. On HardenedBSD or
NetBSD, you'll get a writable page of memory back
** If you get the page back, I put a bit of do-nothing shell code into
the
mapped buffer, then write a function pointer to it and attempt to execute
in
order to cause a page fault there and record the violation is caught
properly,
proving that I didn't get W|X memory
2. attempt to map a page of memory as writable then mprotect() to W|X.
With
PaX, the page stays writable. OpenBSD will abort the processes here
** I did share a version with Red Hat through technical community
channels,
which included proof via live shell code that even if you turn off
execmem
allocation in SELinux, that you get no protection around mprotect and can
still get a shell here.
3. Attempt to map a page of memory as executable and then mprotect() to
W|X.
Again, OpenBSD will abort this but PaX just gives you back what you had
originally

I may be able to share the tool, but it basically just does a subset of
what
is in the paxtest, geared directly at three sub-cases for one security
functional requirement which isn't even mandatory right now. However,
RedHat
didn't want to burn political capital with the Linux kernel devs pushing
for
it when OpenBSD didn't even turn it on. Now that they have, there may be
a
better case to be made in that regard.

-
W. Dean Freeman, CISSP, CSSLP, GCIH
Lead Security Engineer
Mobile: +1.8048158786
wdfree...@acumensecurity.net
http://www.acumensecurity.net

-Original Message-
From: Peter Janos [mailto:peterjan...@mail.com]
Sent: Tuesday, October 11, 2016 2:23 AM
To: W. Dean Freeman 
Subject: Re: RE: OpenBSD PaX Test question

Only two question:

==

1) Increasing kern.stackgap_random=262144 to
kern.stackgap_random=16777216
increases the "14 quality bits" to "20 quality bits".

Stack randomization test (SEGMEXEC) : 20 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 20 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 20 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 20 quality bits (guessed

is this a wise thing to do? Does setting the kern.stackgap_random to
16777216
increases security?

==

2) Can we have the cc-memtest binary or source? Or it is not public.
http://blog.acumensecurity.net/revisiting-wx-with-openbsd-6-0/

==

Many Thanks!

> Sent: Monday, October 10, 2016 at 5:46 PM
> From: "W. Dean Freeman" 
> To: "'Peter Janos'" 
> Subject: RE: OpenBSD PaX Test question
>
> Sure, go ahead.
>
>
>
>
>
>
>
> From: Peter Janos [mailto:peterjan...@mail.com]
> Sent: Monday, October 10, 2016 11:46 AM
> To: W. Dean Freeman 
> Subject: Re: OpenBSD PaX Test question
>
>
>
> can I post this as an anser on stackexchange?
>
> Thank you!
>
> Sent: Monday, October 10, 2016 at 4:36 PM
> From: "W. Dean Freeman"   >
> To: peterjan...@mail.com 
> Subject: OpenBSD PaX Test question
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Peter,
>
> I'm the author of the blog post that you referenced in your stack exch
> ange post.
>
> 

Re: relayd.conf error

[Ali H. Fardan]

On 2016-10-16 01:47, trondd wrote:

This has an error:
listen 127.0.0.1 port 7000
This does not:
listen on 127.0.0.1 port 7003

This has an error:
forward with tls to  6697
The rest of your forward to lines do not.


Tim.


Sorry for late response, this mail server went down for a while, anyway,
thanks Tim!

Re: What are the security features in OpenBSD 6.0 that are by default disabled?

[Mihai Popescu]

...

Still nothing about NSA or other conspiracies in security field?