SystemD sucks - qubes shouldn't use it
Tai...@gmx.com
it is a serious security hole and qubes should consider migrating away
from it by maybe choosing another orgin distro.
http://without-systemd.org/wiki/index.php/Arguments_against_systemd
https://muchweb.me/systemd-nsa-attempt
"The Linux kernel, I believe, is clean. As long as Linus lives, you're
not going to subvert the kernel. Let's just assume that is true for the
sake of argument. If you can't get into the kernel, what is your next
option? You need something low level (PID 1?), ubiquitous, and vast in
scope and complexity.
This describes systemd perfectly. It was almost like it was designed to
touch as much of a Linux system as possible. It has hooks into some many
different subsystems and APIs that it's almost impossible to build a
modern distro with current software without pulling in systemd as a
dependency. This happened almost overnight, and I think there are
malicious forces at work here."
Assuming that it is the NSA is unimaginative, it could be literally be
any combination of interests that are doing this - who wouldn't desire
absolute control and absolute power over 99% of linux systems?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658
I am tired of the "virtualization will protect you!" excuse, it only
goes so far and some systemD issues such as using google DNS by default
are simply inexcusable from a qubes perspective (designed to be a secure
OS, but phoning home like that without asking isn't secure at all)
Linux is about choice, but now the incompetent lennart and red hat are
choosing for you - they are more qualified to make that decision and are
doing it for your own good.
Frank
> On 8 Mar 2017, at 14:50, Tai...@gmx.com Taiidan-at-gmx.com |qubes-mailing-list/Example Allow| <qffya...@sneakemail.com> wrote:
>
> I realize that it is an integral part of fedora and debian (gross), but it is a serious security hole and qubes should consider migrating away from it by maybe choosing another orgin distro.
> http://without-systemd.org/wiki/index.php/Arguments_against_systemd
>
> https://muchweb.me/systemd-nsa-attempt
> "The Linux kernel, I believe, is clean. As long as Linus lives, you're not going to subvert the kernel. Let's just assume that is true for the sake of argument. If you can't get into the kernel, what is your next option? You need something low level (PID 1?), ubiquitous, and vast in scope and complexity.
>
> This describes systemd perfectly. It was almost like it was designed to touch as much of a Linux system as possible. It has hooks into some many different subsystems and APIs that it's almost impossible to build a modern distro with current software without pulling in systemd as a dependency. This happened almost overnight, and I think there are malicious forces at work here."
>
> Assuming that it is the NSA is unimaginative, it could be literally be any combination of interests that are doing this - who wouldn't desire absolute control and absolute power over 99% of linux systems?
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658
> I am tired of the "virtualization will protect you!" excuse, it only goes so far and some systemD issues such as using google DNS by default
Nobody is forcing you to use Qubes and frankly, if it is good enough for the Qubes team, I am not the one to tell Joanna something about security... Are you?
Cheers, Frank
> are simply inexcusable from a qubes perspective (designed to be a secure OS, but phoning home like that without asking isn't secure at all)
>
> Linux is about choice, but now the incompetent lennart and red hat are choosing for you - they are more qualified to make that decision and are doing it for your own good.
>
> You received this message because you are subscribed to the Google Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7acfa3f6-d9ae-a5f8-87c4-998b28f574fc%40gmx.com.
> For more options, visit https://groups.google.com/d/optout.
Unman
problem. I'd like you to explain why you think it is.
There's been some discussion on this in the past. Qubes has some
dependency on systemd, but there is code for sysvinit alternatives,
which you should be able to work with.
Where there isn't an existing alternative you should be able to find one
fairly readily.
Linux IS about choice - if you want to exercise your choice to use Qubes
without systemd then you should start work and provide PRs. They would be
accepted and many people would thank you.
Daniel Moerner
> I realize that it is an integral part of fedora and debian (gross), but
> it is a serious security hole and qubes should consider migrating away
> from it by maybe choosing another orgin distro.
It would be helpful for you to make clear what exactly in that pile of links is a threat to Qubes.
More generally, I think you significantly underestimate the benefits Qubes receives from integration with established distributions. These distributions have more users, more developers, better infrastructure, etc. All of this contributes to security, and the infrastructure is particularly important when it comes to trusting the distributions you use for your templates. The alternative distributions have much smaller userbases. The same holds true for systemd alternatives. How long will OpenRC, or sinit, or uinit, or the latest new proposed replacement be supported? Even if systemd has some problems, I think the benefits we get from Fedora and Debian outweigh the costs.
Daniel
Chris Laprise
thinks Linus is fallible it is the people on this list.
Systemd may not be the best thing to happen to Linux, but compared to
relying on the chronic ineptitude of sysv system state handling (esp.
PC/laptop power modes) its a godsend.
Systemd exists because Apple made it abundantly clear with OS X launchd
that sysv init couldn't cut the mustard... and then Ubuntu followed suit
with Upstart. Eventually, systemd was shown to be better engineered than
Upstart. IMO, advocating a return to init instead of another
launchd-like arbiter shows bad judgment.
>
> This describes systemd perfectly. It was almost like it was designed to
> touch as much of a Linux system as possible. It has hooks into some many
> different subsystems and APIs that it's almost impossible to build a
> modern distro with current software without pulling in systemd as a
> dependency. This happened almost overnight, and I think there are
> malicious forces at work here."
work as an unyielding rule for modern systems which require lots of
vertical integration of useful hardware features.
Network Manager taking over from the old, sclerotic network layer is a
prime example of this. MAC address anonymization using the old "small
tools used together" philosophy gave us 'macchanger' and scripts that
couldn't deliver the sought-after behavior without making the user bend
over backwards to accommodate the patchy device management (restart your
netVM after waking from sleep, etc).
It shows that simplicity applied in the wrong way and the wrong places
(or adhered to like fundamentalist religion) actually makes systems more
*brittle* and less secure.
Xen allows us a much better mixture of complexity and simplicity.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658
Interesting issue, but not related to the question of design complexity.
This could be entered as a Qubes issue to address the question of
default settings (I don't want the Google settings either).
--
Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
sm8ax1
>
>> "The Linux kernel, I believe, is clean.
>
> You lost me right there. I don't believe in hero worship, and if anyone
> thinks Linus is fallible it is the people on this list.
Privilege escalation, uninitialized pointers, race conditions, you name
it, vulns are found in the kernel at what's in my opinion a somewhat
alarming rate. I seem to think a developer loudly brought up this
growing problem at linux.conf or a another event a year or two ago, but
the details aren't coming to me. I don't even follow kernel development
and I hear about security problems way more often than I'd like to for
ring0 code.
For some insight into why the Linux kernel is not as secure as you
think, in both rant style and by-example, regularly posted referring to
over a decade's worth of incidents and poor decisions, all you have to
do is visit https://www.grsecurity.net/
I'm not saying that Linux is a bad thing or the developers don't care or
that another OS is better, but to say the kernel "is clean" is just
plain wrong.
Tai...@gmx.com:
> I am tired of the "virtualization will protect you!" excuse, it only
> goes so far and some systemD issues such as using google DNS by default
> are simply inexcusable from a qubes perspective (designed to be a secure
> OS, but phoning home like that without asking isn't secure at all)
distros do in fact. You can also of course set your own at run-time, but
most users won't do this and I agree Qubes should make an attempt to
protect users from that. systemd-timesyncd has a similar problem with
timeservers.
Actually, do these settings even matter in Qubes' default state?
My systemd-networkd.service is disabled and not running in my sys-net,
which is the way it was installed.
Further, /etc/resolv.conf is
> # Generated by NetworkManager
> nameserver 192.168.1.1
Which is the DNS server configured by DHCP.
Where does systemd-resolved come into play?
-------------------------------------------------
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!
Drew White
I'm currently in the middle of getting Qubes to work on Slackware, i.e. no systemd.
It's taking a bit of time to get everything right though, but I believe that in the end, it will be fully functional.
The only reason it's taking so long is because the Qubes Developers don't know the answers to the questions that I asked regarding Qubes. It's either that or they just refuse to answer to protect something that's open-source.
As far as I know, slackware will never be using systemd. This is the reason why I am doing it.
Someone ages ago said they would be building a template for slackware integrated, but that didn't go anywhere beyond that as far as they had posted. So, I started doing it myself.
Soon, there will be a MORE SECURE version of Qubes available, and all updates still coming from qubes-developers themselves, or else it may have to be an off-branch version if their coding doesn't allow for non-systemd in the future.
cooloutac
I dunno what it is. I started linux with fedora but itseems it started to get super buggy after fedora19 to the point I switched to debian and ignored the false extra security I thought it gave me. I felt like a bigger target using it for some reason.
I thought problems were due to switch to dnf which just made updates unbearable as if some sick joke on fedora users. but all sorts of baremetal problems with it. maybe it was the change to systemd? or Kernels keep getting worse? More people using linux but they don't really use it? lol I dunno I started on Fedora 14 ir 15 not sure when it got systemd actually. Debian is stable and quiet. I made the switch debian. arch can be real lighweight and less buggy but has same kernel probs as fedora. They similar in ways. fedora 22 was nail in coffin for me. Its like let me put a target on my forehead with the word dumb and a bullseye. One good thing it gets updates super fast. Alot of qubes user complaints areabout poor support for cutting edge hardware. Think thats reason qubes uses fedora. I'd rather fedora then ubuntu lmao...
I use to use slackopuppy it was great, talk about lightweight. and fully functional. security conscious too.
cooloutac
I'm basically at mercy of a default setup lol. But I think thats part of qubes goal. It has the misnomer of being called for nerds or enthusiasts. But its really for noobs. The hard part is just taking a step in these waters of a new world, even for most security experts.
The hard part is just accepting the fact you will be compartmentalizing diff aspects of your daily activity on your pc. Its a different way of thinking.
Its about accepting the fact you are never 100% secure and its just a matter of how persistent your assailant is. No matter what OS you are using. Everyone gets compromised imo, even most security experts. The only people that don't are people that use their computers like monks. All we can do most of the time is mitigate it.
Drew White
> Well I'm just a layman but from my little experience i prefer systemd cause its easier to handle running system processes. but from bootup time standpoint it seems to make no diff.
>
systemd is bad, things were simpler and easier without it.
> I dunno what it is. I started linux with fedora but itseems it started to get super buggy after fedora19 to the point I switched to debian and ignored the false extra security I thought it gave me. I felt like a bigger target using it for some reason.
>
fedora 19, when they started to bring in systemd on a persons choice?
or was it compulsory by then and no choice?
> I thought problems were due to switch to dnf which just made updates unbearable as if some sick joke on fedora users. but all sorts of baremetal problems with it. maybe it was the change to systemd? or Kernels keep getting worse? More people using linux but they don't really use it? lol I dunno I started on Fedora 14 ir 15 not sure when it got systemd actually. Debian is stable and quiet. I made the switch debian. arch can be real lighweight and less buggy but has same kernel probs as fedora. They similar in ways. fedora 22 was nail in coffin for me. Its like let me put a target on my forehead with the word dumb and a bullseye. One good thing it gets updates super fast. Alot of qubes user complaints areabout poor support for cutting edge hardware. Think thats reason qubes uses fedora. I'd rather fedora then ubuntu lmao...
>
I'd rather slackware because it has no systemd, other than that I use CentOS 5, and some early 6 with the less crap that they changed in it. fedora is a day0 attack heaven. super vulnerable. not to mention systemd makes it even more vulnerable.
> I use to use slackopuppy it was great, talk about lightweight. and fully functional. security conscious too.
never tried it. I'll have to take a look.
Drew White
> My problem with Qubes is that i'm still noob. I don't even know what alot of system processes are or what they do. Qubes is more complicated then a normal os even just to monitor network traffic. I'm mostly in the dark compared to on bare metal os.
>
I know more about qubes than the developers do by now.
monitoring is easy, just have a proxy that does it after the netvm.
NetVM -> Firewall/Proxy running WireShark or similar -> AppVM/HVM
> I'm basically at mercy of a default setup lol. But I think thats part of qubes goal. It has the misnomer of being called for nerds or enthusiasts. But its really for noobs. The hard part is just taking a step in these waters of a new world, even for most security experts.
>
I wrote my own applications for qubes because the developers wouldn't fix things and didn't change things to use less RAM.
I wrote my own manager that uses only 200 MB VRAM, instead of the current one that uses over 1 GB VRAM. (Approximations)
Qubes is built for end users, not nerds or developers or anything (or so they claimed, will post reference later).
> The hard part is just accepting the fact you will be compartmentalizing diff aspects of your daily activity on your pc. Its a different way of thinking.
>
it is a different way for many people. Those of us that are like me, and are developers and such, we use virtualisation every day just to do our jobs.
> Its about accepting the fact you are never 100% secure and its just a matter of how persistent your assailant is. No matter what OS you are using. Everyone gets compromised imo, even most security experts. The only people that don't are people that use their computers like monks. All we can do most of the time is mitigate it.
Accept you aren't secure. Accept that you are compromised. Then try your best to prevent things from going wrong.
It's always good to prevent what you can.
I have a way of doing things that permits me to protect myself up the wahzoo.
More advanced than the way qubes initially did it.
It involves me doing different things with the iptables rules, but it's workable.
I've done things and tested things, even the vulnerabilities that they say there are that makes qubes super duper easy to break, and mine hasn't broken or had that vulnerability.
Default setups, they can cause issues.
SystemD, issues.
Hopefully one day, things will be back to being better, but until then, we just have to try to protect ourselves as best as we can. What else can we do when people like Google and Microsoft and all those others are trying to steal your data and take over your life and your pc and everything about you, then sell your data to the everyone....
Holger Levsen
> systemd is bad, things were simpler and easier without it.
a 1000 people) is more secure and simpler? That's a curious POV…
--
cheers,
Holger
cooloutac
true. Why not just use wireshark in sys-net, since its considered unsafe anyways?
The problem for me is identifying what vm and what process is causing the traffic. To use baremetal methods on every vm is impractical.
I still never figured out how to make the firewall scripts to control everything outgoing. I still don't even believe its possible for some system processes. Sure i've made iptables rules file on baremetal linux no probs. But I have to be honest, with Qubes its too complicated for me.
another issue for is monitoring hdd activity in similar manner.
Jean-Philippe Ouellet
> I wrote my own applications for qubes because the developers wouldn't fix things and didn't change things to use less RAM.
> I wrote my own manager that uses only 200 MB VRAM, instead of the current one that uses over 1 GB VRAM. (Approximations)
Drew White
Well, I will have to fix it up to make it available.
It's not exactly "end-user" friendly at the moment.
But in the long run, I just may.
It is NOT open-source though.
And many of the things are hard-coded to what I use, so I'd have to build an options section for that aspect.
I'll let you know when it's done.
Drew White
> On Friday, March 10, 2017 at 1:14:47 AM UTC-5, Drew White wrote:
> > On Friday, 10 March 2017 15:36:49 UTC+11, cooloutac wrote:
> > > My problem with Qubes is that i'm still noob. I don't even know what alot of system processes are or what they do. Qubes is more complicated then a normal os even just to monitor network traffic. I'm mostly in the dark compared to on bare metal os.
> > >
> >
> > I know more about qubes than the developers do by now.
> > monitoring is easy, just have a proxy that does it after the netvm.
> > NetVM -> Firewall/Proxy running WireShark or similar -> AppVM/HVM
> >
> >
> > > I'm basically at mercy of a default setup lol. But I think thats part of qubes goal. It has the misnomer of being called for nerds or enthusiasts. But its really for noobs. The hard part is just taking a step in these waters of a new world, even for most security experts.
> > >
> >
> > I wrote my own applications for qubes because the developers wouldn't fix things and didn't change things to use less RAM.
> > I wrote my own manager that uses only 200 MB VRAM, instead of the current one that uses over 1 GB VRAM. (Approximations)
> >
> > Qubes is built for end users, not nerds or developers or anything (or so they claimed, will post reference later).
> >
> > > The hard part is just accepting the fact you will be compartmentalizing diff aspects of your daily activity on your pc. Its a different way of thinking.
> > >
> >
> > it is a different way for many people. Those of us that are like me, and are developers and such, we use virtualisation every day just to do our jobs.
> >
> >
> > > Its about accepting the fact you are never 100% secure and its just a matter of how persistent your assailant is. No matter what OS you are using. Everyone gets compromised imo, even most security experts. The only people that don't are people that use their computers like monks. All we can do most of the time is mitigate it.
> >
> > Accept you aren't secure. Accept that you are compromised. Then try your best to prevent things from going wrong.
> >
> > It's always good to prevent what you can.
> >
> > I have a way of doing things that permits me to protect myself up the wahzoo.
> >
> > More advanced than the way qubes initially did it.
> > It involves me doing different things with the iptables rules, but it's workable.
> >
> > I've done things and tested things, even the vulnerabilities that they say there are that makes qubes super duper easy to break, and mine hasn't broken or had that vulnerability.
> >
> > Default setups, they can cause issues.
> > SystemD, issues.
> >
> > Hopefully one day, things will be back to being better, but until then, we just have to try to protect ourselves as best as we can. What else can we do when people like Google and Microsoft and all those others are trying to steal your data and take over your life and your pc and everything about you, then sell your data to the everyone....
>
> true. Why not just use wireshark in sys-net, since its considered unsafe anyways?
> The problem for me is identifying what vm and what process is causing the traffic. To use baremetal methods on every vm is impractical.
true, but that's where certain things come in handy.
That's one thing I will look at adding, thanks for the thought.
> I still never figured out how to make the firewall scripts to control everything outgoing. I still don't even believe its possible for some system processes. Sure i've made iptables rules file on baremetal linux no probs. But I have to be honest, with Qubes its too complicated for me.
>
It's easy, use the firewall editor for the VMs.
> another issue for is monitoring hdd activity in similar manner.
On Dom0, use disk monitoring software.
cooloutac
You can accomplish same thing with sys-net but I guess its more convenient to do with a proxyvm, as well for backing it up.
The firewall editor in qubes-manager doesn't block everything, neither would the script files, like some qubes system processes. The whole point for me would be to identify and more importantly LOG, ALL traffic with iptables. I know it sounds crazy to some but thats what I have done on every linux system all my life along with file integrity logs. Using programs to parse it or just eyeball it. Always Ignoring myths about overhead and storage space. But when we move to ipv6 I will be lost anyways...And with such sophisticated attackers and systems getting more complicated its probably becoming more silly.
The first time I installed qubes I put iotop on dom0. Was one of my first questions on the forums. But Monitoring hdd activity is the same issue for me as network traffic, narrowing it down to the specific process and on which vm.
With Qubes I feel like a total noob in the dark, but i guess thats the whole point. I don;t need to investigate anything weird. If I get paranoid I just delete the vm!!
I give up on computer security nowadays anyways, so Qubes is the perfect option for me. I'm just the avg user, but with Qubes I;m more isolated then the avg os. It seems all anyone can do is stop random actors to begin with. Most "experts" are just too arrogant to admit it or in denial. To me now its more about my use of my machine then how its monitored or hardened. Its still all about user actions, even though nowadays they are less to blame and bear less responsibility for vulnerabilities that exist. I can;t live like a monk on my pc so I have to live with compromise.
But I guess if qubes was to become more popular some geniuses out there would create monitoring tools designed for it. Cause doing things the old fashioned way is impractical with multiple vms. Qubes devs would probably say I am naive for thinking I can catch something with monitoring tools.. I say I probably couldn't prove anything, but i;m more likely to find anomalies making me paranoid prompting me to use the delete button on the vm haha.