It would be palatable to have a "secure.mk" under /usr/ports/Mk/Uses
that enables pie, relro, now, noexecstack and elfctl features. Then
port users can enable/disable their (elfctl) default features as they wish.
I look forward to removing long lists of category/ports from my
make.conf that make these adjustments at the moment. All of my internet
facing services use the above settings (sans elfctl). We also have a
production system that uses these applications with aslr and stackgap=1
under i386 successfully. :)
I'd also throw cfo into the mix, but small steps grasshopper...
To Ed, I like the notion of elfctl because it allows me to set once and
forget about how the executable should run, so setting a default at
buildtime is a good idea. (I had to think about this for awhile as I
prefer the explicitness of proccontrol, however elfctl is akin to chmod
in that its a control that isn't set everytime a program is run.)
I supposed proccontrol will override elfctl settings?
Regards, Dewayne
PS The elfctl manpage's History states that elfctl first appeared in
FBSD 13, I'm using 12.1 Stable ;)
that On 5/05/2020 1:11 am, Ed Maste wrote:> On Thu, 23 Apr 2020 at 11:38, Brooks Davis <brooks at freebsd.org>
wrote:
>>
>>> I was thinking if it is possible to come up with such wide test
>>> coverage to test every single application from the base system. Do
you
>>> think it is achievable or should we rather follow the approach to
do
>>> as many tests as possible, but rely on the community feedback to
catch
>>> the corner cases (like the ntpd issue mentioned in this thread)?
>>> What about the ports?
>>
>> If we gate on full testing we'll never move forward. We had a GSoC
>> project a few years ago to try to generate lame tests for each program,
>> if someone picked that up, we could get better coverage fairly
>> quickly, but it would still be far from complete.
>
> Indeed, having a basic smoke test for as much of the base system as
> possible is a good initial step. I suspect it won't take very long to
> have confidence in turning on options for the base system, but ports
> will be a much longer process.
>
> For ports I think the first thing that needs to happen is to have some
> infrastructure in ports itself to allow individual ports to indicate
> (via elfctl) that they are not compatible with certain options; with
> that in place it should be trivial to start marking individual ports.
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at
freebsd.org"
>