Re: [qubes-users] SystemD sucks - qubes shouldn't use it

2017-03-09 Thread sm8ax1
Chris Laprise:
> On 03/08/2017 08:50 AM, taii...@gmx.com wrote:
> 
>> "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.

Thanks for addressing this, Chris.

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.

taii...@gmx.com:
> 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)

It's easy enough to override the defaults at compile-time, and most
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!  

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9676f5aa-ec5a-b5fa-0653-8a3292a15e73%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] SystemD sucks - qubes shouldn't use it

2017-03-09 Thread Chris Laprise

On 03/08/2017 08:50 AM, taii...@gmx.com wrote:


"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.


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."


You can have "small and separate tools" some of the time, but it doesn't 
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

--
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/031d5456-4c92-9354-f403-99ff4f929650%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] SystemD sucks - qubes shouldn't use it

2017-03-08 Thread Unman
On Wed, Mar 08, 2017 at 08:50:59AM -0500, taii...@gmx.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 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.

Frankly, the use of systemd in dom0 doesn't strike me as a huge
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.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170308151010.GB2649%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] SystemD sucks - qubes shouldn't use it

2017-03-08 Thread Frank


> On 8 Mar 2017, at 14:50, taii...@gmx.com Taiidan-at-gmx.com 
> |qubes-mailing-list/Example Allow|  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

And how is it supposed to do this in dom0 without ANY network connection?

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+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@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.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7734-1488982678-787612%40sneakemail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] SystemD sucks - qubes shouldn't use it

2017-03-08 Thread taii...@gmx.com
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 
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@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.