:: Re: [Dng] Hardened Devuan (was Re: …
Top Page
Delete this message
Reply to this message
Author: miroslav.rovis1
Date:  
To: dng
Subject: Re: [Dng] Hardened Devuan (was Re: Plan for Devuan to use Mozilla products as is)
On Fri, Mar 06, 2015 at 08:33:20PM +0100, Jaromil wrote:
>
> dear Miroslav,
>
> On Fri, 06 Mar 2015, miroslav.rovis1@??? wrote:
>
> > I hope to be able to continue my Grsecurity/Pax Deployment in Devuan for
> > the Newbies (or of a similar title), like I did in Debian Forums (see my
> > first message in this thread). And about the rest of non-poeterware (and
> > related like, for me, dbus). Maybe in the Wiki, sure Devuan Wiki.
>
> yes, the gitlab on https://git.devuan.org good that you made a login.
>
> people can contact me, Nextime or Hellekin to have groups or projects
> created and its wiki can be used for documentation.

I've taken notice, kind brother in *nix! I'll also browse more
extensively to see how things are faring. But I have to remind you that
I am only an advanced user. Capable, I think, to transfer what I know
(and what I will yet learn), to less advanced users, though. Surely,
when things call for an expert insight, I'll have to ask for help.

> I will be among the newbies following your guides: last time I've used
> grsecurity was long time ago, before I gave up the maintainance of
> dyne.org servers to more volunteers. Wondering how much has changed in
> 10 years or so.

If I'm moderated by the Elder members with insight into, and
understanding of, the code, and the architectural/programming
design/other expert aspects, where necessary (and I hope there already
are members of Devuan who can oversee my work, prior to publishing it),
then maybe I can serve the community successfully.

And we can ask for help, if more difficult issues arise, and when they
are really needed, both spender and PaX Team from grsecurity.net have
shown to be available, as are the experts for hardened from the higher
echalons of the Gentoo Foundation, such as blueness, the capable
Accademic behind Gentoo grsecurity-hardening.

A sidenote. I've already pointed to my slowliness, and it shows here:
I've been into the preparation of this e-mail if I view it since I sent
my first mail, for roughly one third of the time elapsed since then...
And have been writing this message, in which I want to reply to both
you, Jaromil, and Neo Futur, and hellekin, and others, at once. So: I am
slow... Count with it. And may Vis Major (Latin) disband other possible
hindrances to my future work.
> > If that is the space that Jaromil is talking about? (I can log in, I
> > also posted my ssh key, I hope I'll be able to contribute somewhere
> > somehow).
> >
> > ...Aaah, the beta, we're all impatient for the beta release!
>
> there is some more time to be waited, but I'm also impatient indeed.
>
> thanks for your enthusiasm :^)

I dream of a successful fight of FOSS Linux for true
security/privacy/freedom.
> ciao

Mi piacerebbe scriverti in italiano, ma altri non capirebbero. Perciò...
(translation: I'd like to write to you in Italian, but others would not
understand, So...)

On Fri, Mar 06, 2015 at 03:19:29PM -0300, hellekin wrote:
> On 03/06/15 05:06, Neo Futur wrote:
> >> the Grsecurity/Pax hardening of the kernel, will you think of it,
> >> instead of SELinux, or as an option besides SELinux? It sure will be
> >> attainable in the way I got it in Debian in that Tip, but official
> >> support would be so great!
> >
> > https://git.devuan.org/groups/hardened
> >
> > we are a few guys planning to try and maintain a grsec kernel for
> > devuan, for now we are waiting for a bevuan beta version before
> > starting working on it.
> > anyone interested, feel free to join !
> >
> *** I'm so happy to see this group. I've been using this kernel lately,
> running on Parabola:
>
> 3.14.34-gnu-201502271838-1-lts-grsec-knock
>
> GRSecurity, and Knock support. Knock is a kernel patch that enables
> single packet port knocking [0], thwarting common scanning attacks. I
> would love to see this running on Devuan. Parabola GNU/Linux was the
> first distro to deploy it, and I've been using it happily with SSH.
>
> ==
> hk
>
> [0]: https://gnunet.org/kirsch2014knock


I left the above in my message, because I feel it is important.

> -- 
>  _ _     We are free to share code and we code to share freedom
> (_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/


On Fri, Mar 06, 2015 at 07:22:16PM -0500, Neo Futur wrote:
> at the beginning we plan :
>
> * to use only the pax options of the grsec kernel, no rbac enabled
> * to work on vanilla sources or gentoo hardened sources

I can say grsec-hardened gentoo works great on my systems, and using
their kernel could decrease the workload... But maybe only as far as
hardening goes? What I do know, from experience, and I do have a nasty
regime, against me, currenty in power in Croatia (not saying this for
politics; some of my friends have to go to jail or worse before I
mention politics in my messages here, but because of intrusions that I
suffered, for years, all findable by my name, Miroslav Rovis, in Gentoo
Fora and Grsecurity Fora, maybe some in Debian Fora --not sure for the
last ones)...

[What I do know, from experience], is that the Gentoo install was always
much harder to break in than Debian was. Again, study my posts in those
if someone has doubts. Gentoo has much better and more carefully
hardened toolchain for package compilation. That can be read about in
Gentoo Wiki (search for `hardened toolchain')...

But the problem is compatibility, maybe. You probably can not easily
apply the Gentoo type hardened toolchain to produce well hardened
packages such as those that Gentoo compiles, in Devaun... from the
existing Debian package repositories... I haven't compiled anything but
the kernel, in Debian, yet. Not familiar with development in
Debian/Devuan, yet.
> * no debian patches, no exotic patches
> * shipping the kernel with warnings that, as a default, java wont work
> with a secure kernel, and possibly any other graphical applications
> doing dirty stuff with memory ( buffer overflow, relocations and much
> more )

The users should know that bloat such as Gnome and KDE can have problems
to work, or sometimes can only work after a lot of dedicated work, with
a hardened system. I don't want the Gnome/KDE/other-similar-desktops
also because of dbus, they, most of them if not all, use dbus, and don't
work without dbus, and unless someone defeats my arguments on the use of
dbus (and its encryption and its RPCs) to mess up you machine for third
parties' use, as I explained in my newest Gentoo post (the link given in
my previous message), and I mean defeat my arguments, not just dismiss
them, I intend to always advise users against dbus, as well.

And the lack of at least some of oversophisticated and user unpowering
or depowering (contrary to enpowering) desktops like GNOME/KDE/others
above... may lose us some potential users. People are massively
brainwashable, enough for them to be easily moulded as the
one-ring-to-rule-them-all cravers wish. And we will see propaganda
winning over here and there for the non-true-FOSS-systemd distros...

So we are against systems here, as those few cravers mostly control the
systems (never totally though, it's very mixed). However, the
legislature of most of the world countries (also Croatia) is on our
side: privacy is sacred in most Constitutions of most countries in the
world --and especially in all of those that claim to be democracies, I
believe--, and we can always claim our rights. We fight against their
secret rule, but have the law, they don't, we do, on our side, when it
comes to fights against censorship and intrusions by the various
systems/regimes/other-third-parties.

Looking at the above paragraph: marketing could be a problem if some of
the glitz of the bloat is missing to seduce the eyes of the newbie...
but only if poeple with true alegiance to FOSS, and capable of the kind
of marketing necessary for FOSS (only for survival, not for me, I can
live so poorly that some of you wouldn't even believe), I'm only talking
infrastrucure for the projects... marketing could be a problem, but only
if poeple with true alegiance to FOSS were to be missing from in among
our members and don't come to our aide. Do we already have such members?
But I'm going too far, not competent here.
>
> as soon as we have a devuan beta version we feel confident enough to
> install on at least one dedicated server ( something like dell r210 )
> and on a laptop ( something like a thinkpad ), we ll start packaging a
> grsec patched kernel.
>
>
> speaking of installing on a dedicated server, do we have plans to
> provide some kind of easy install system to install on a server from a
> rescue mode ? ( not everyone have full kvm access to install
> graphically, many datacenters provide only the rescue mode )
>

I have no exerience with online servers and many users using them, I
could only transfer the knowledge and experience of mine, to simple
desktop workstation users.
>
> On Fri, Mar 6, 2015 at 6:27 PM, Adam Borowski <kilobyte@???> wrote:
> > On Fri, Mar 06, 2015 at 03:19:29PM -0300, hellekin wrote:
> >> *** I'm so happy to see this group. I've been using this kernel lately,

...[snip: already brought up above]...
> >
> > It looks like Knock breaks everything TCP SQN is used for, including even
> > such basics as packet retransmission/duplication detection. I've read the
> > LKML discussion to see if I'm missing something, but apparently, I don't.
> >
> > As such, I'd say Knock has no place on a distribution kernel.
> >

I'm only taking notice of this above.

On Fri, Mar 06, 2015 at 08:37:02PM -0500, Neo Futur wrote:
> also answering here to jaromil about a grsec question on another thread :

...[snip: already brought up above]...
> dyne.org servers to more volunteers. Wondering how much has changed in
> 10 years or so.
> quite a bit, new options and new features are regularly added :
>
> https://grsecurity.net/changelog-stable.txt
> https://grsecurity.net/features.php
> https://grsecurity.net/compare.php
>
> the patches are very actively maintained and working very well on
> gentoo hardened, but once again I use only the sanitizing features,
> not the RBAC system.
>
> as a sysadmin, grsec have helped me quite a bit those last ten years,
> most of the kernel security problems, 0 days, local roots . . . have
> been useless against my grsec kernels ;) usefull ehen you provide a
> shell to most of your customers/users !
>

Obviously, you cater for server-people. And I want everybody to see that
praise of grsecurity above.

Not ever having heard of Knock (my first reading of it is in this mailing
list), I can't yet judge about it, but it looks apealing to me.

But I can say my systems are so much safer since I finally deployed the
RBAC system on top of grsecurity-hardened kernel.

The RBAC system (which I understand that, for many readers, this may be
their first reading about, just like for me, it is my first hearing of
Knock) could show very appealing to people, if it is presented well. And
presented demonstrably.

Maybe even in packet captures from someone's system's time online,
combined with, where it applies, screencasts of the same time: those can
be appealing, if you get to really capture an attack by some third
party, which your deployed grsecurity/RBAC defended your system from,
such as I captured Schmoog and Yooch in attack, go and see, since the
Google defenders seem not to want to --I already gave previously this
link below--, or don't understand (but they're forgiven in either of the
cases), [go and see] how I captured Schmoog (my term of endearment for
Google) and Yooch (pronounced with `ch' as in `Loch Ness' or as in some
Arabic and Hebrew words, my term of endearment for Yahoo), [how I
captured Schmoog and Yooch] clickjacking my connection to send mail from
my machine:

a clickjacking that only packets captured show:
Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion
https://forums.gentoo.org/viewtopic-t-999436.html#7685200

To get such stuff proving grsecurity and RBAC defending your system,
such as the above proves an intrusion (sadly, to explain packets to a
regular user is very much work), would be a scoop that helps
appreciation from users and onlookers... But not the brainwashable
onlookers. Sadly, little can be done for those.

---
Here's my informal, but frank, in this Big Brotherly age, which only
non-truthful, or for some other reason being, at the time of saying so,
defective, people can say it is not such, here's my informal, but frank,
introduction to RBAC for readers, for whom this may be their first
reading about it. (I'm sending it to Devuan maling list as an incomplete
idea for some future presentation.)

RBAC or Role Base Access Control is the layer that finalizes what does
grsecurity --which includes PaX-- and which [the grsecurity] is a
collection of patches that, to explain it in lay terms: fix what Linus
Torvalds, the little god of the Linux kernel, since he is its inventor
and remains its main programmer, or more exactly the decider-programmer,
may have even deliberately introduced (first the Linux Security Model or
LSM and, later, the linux capabilities; read in the links in my
signature below)...

[Grsecurity fixes what Linus introduced] for, mild expression: third
parties, into the Linux kernel, the engine of any FOSS Linux --or
GNU/Linux-- operating system, such as the Devuan, which is rising to
become the new sun among the distros, we hope... after the Debian
false-FOSS-systemd-and-related-bad-choices suicide...

(Systemd is not true Free Open Source Software, it is there for third
parties, and invented for third parties, and financed by third parties,
it is not there for the user enpowerment, but depowerment, it is there
for the control over users, not for control by users of their own
e-turf.)

RBAC is the layer on top of the grsecurity-patched kernel, that fixes
what cannot be fixed through patching of the kernel for one or another
reason.

Stuff such as linux capabilities (issue `man capabilities' and see the
enormous potential for privilege escalation and planting binaries into
`intruded system' --read: `your system', brother in *nix--, and
especially, read what the author of grsecurity, Bradley spender
Spengler, writes about it, it's in my signature, and probably in
signatures of my future messages here)...

[Stuff such as linux capabilities] by means of which a third party can
gain arbitrary control over your machine, dear FOSS Linux and future
Devuan user, such stuff is tackled with RBAC successfully (but I will
only have sufficiently extensive experience of it, hopefully, with time,
to be able to demonstrate it).
---

Like I said the above is an incomplete idea for a
presentation/introduction/explanation for our future users.

And I now, after all this writing, have to first see if I'm not too late
for simply sending this without first adding anything to this. Late
replying, like this one of mine, may add a little confusion, without
possibly necessary explanations... It's been hours since I read the
replies to me, and other new messages from the Devuan mailing list.
Apparently, it should be fine and not overly late just sending this.
--
Miroslav Rovis, Zagreb, Croatia
http://www.CroatiaFidelis.hr
Try refute: rootkit hooks in kernel
( http://www.crmbuyer.com/story/39565.html ),
linux capabilities for intrusion
( https://forums.grsecurity.net/viewtopic.php?f=7&t=2522 )