[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#796642: marked as done (debian-policy: hardening is an afterthought and should never be)

Your message dated Sat, 31 Dec 2016 19:01:35 -0800
with message-id <87vatz5vqo.fsf@hope.eyrie.org>
and subject line Re: Bug#796642: debian-policy: hardening is an afterthought and should never be
has caused the Debian Bug report #796642,
regarding debian-policy: hardening is an afterthought and should never be
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
796642: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796642
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: debian-policy
Severity: normal
Tags: newcomer upstream security

Hardening according to many devs I have spoken with is an afterthought,
especially post install. This is like reccommending Debian to be hacked.
Im not saying one move can stop a hacker, security is always an ongoing
situation, either you are ahead of the curve, or you have fallen behind.

Programming like this and packaging with this mindset is just no good.

There are MANY ways one can harden a debian install, most are common sense
items. Others are easy to implement solutions that could be setup by the
installer or its packages BY DEFAULT. Many of these solutions protect the end
user and help to secure a network environment. IGNORING ME is asking for
trouble.

Simple things:

SELinux ENABLED and ENFORCING and INSTALLED WITH SeTroubleshoot [like Fedora
has]
Harden flags set AND ENFORCED on build environment(harden package)
Use of RELRO and PIE where possible
NOEXEC and NOSUID on /tmp and /var/tmp
VA.randomize(HEAP?) set by default in /etc/sysctl.conf [I have many tweaks
here, some for gigabit ethernet]

ENCRYPTED SWAP enabled by DEFAULT with a RANDOM key
/etc/securetty set to near nothing or nothing with comments on why nothing is
here and the local login methods commented.
ufw/gufw installed and set on startup
fail2ban installed and base configured
password backups disabled (why is this even a thought to enable this?)
grub password protection should work (it doesnt and not only that but users and
admins should have a clear cut method to enable this)
Documentation of mainline system installed and linked to in ~/Desktop. (Like a
pdf of the debian handbook...)
non-free video (and other hardware) detection and installation help offered
post install [like ubuntu has]

This is what is on the top of my head, as I have BEEN IGNORED in the past by
people saying "well this isnt our policy, make a hardening reccomends..." GUESS
WHAT? IM MAKING IT. Debian is INSECURE by default. Neither admins nor end-users
want the headache of figuring out all of these things by themselves, and all of
this takes TIME to implement. PEOPLE FORGET. ADMINS get busy with other tasks
like merging in a user database. USERS get busy with packages and putting all
thier files back on the system.

Dunno about you, it usually takes me DAYS to get all of my packages installed
and setup correctly.

And AM I the only one to semi-automate a lockdown and install method? (even if
invoked by hand)



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

--- End Message ---
--- Begin Message --- 
Richard Jasmin <frazzledjazz@gmail.com> writes:

> Hardening according to many devs I have spoken with is an afterthought,
> especially post install. This is like reccommending Debian to be hacked.
> Im not saying one move can stop a hacker, security is always an ongoing
> situation, either you are ahead of the curve, or you have fallen behind.

> Programming like this and packaging with this mindset is just no good.

I completely agree with your concerns and with many of your
recommendations, but I'm afraid that this is more of a position statement
than an actionable bug report.  There isn't any good path forward for
using this as a bug report to make changes to Debian Policy, since it's
such a broad wishlist of different requests.

I'm therefore closing it out as unactionable.  However, more specific,
targeted proposals for how to add specific security and hardening
requirements to Policy's requirements for Debian packages are very
welcome!  As a start, you (or anyone else who is interested in this) may
want to look at which of your wishlist items aren't already in place, and
try to figure out how Debian Policy wording could be changed to make this
a requirement.  Or what prerequisites would need to be in place before
that could happen.

(Realistically, most of this work happens elsewhere, either in dpkg on
hardening flags, in the compiler, or in the maintenance of packages like
SELinux or AppArmor.)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

--- End Message ---
Reply to: