Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Always Learning]

On Sun, 2017-04-16 at 18:25 +0100, Pete Biggs wrote:


> Yes. And despite what people think, those agencies don't have super
> powers. They have tools to help them, and lots of resources, but
> nothing out of the ordinary.

Untrue. They are in advance of mainstream developments. Spying has
existed for thousands, of years *and* it is their job to discover and
then discretely monitor what is going-on.

It is never one team doing everything but many highly specialist teams
dedicated to particular aspects of intelligence gathering which they do
expertly, and impressively, well.

All countries monitor, by all available means, what is happening in
their own territory and around the world. Just because, for example, the
USA and Russia are not officially loving buddies it never ever prevents
their intelligence agencies covertly sharing intelligence of mutual
interest. It is a incestuous world with an international web of contacts
doing favours and often disregarding their own government's official
political pronouncements.

>  There is nothing that the NSA can do that can't be done by other
>  agencies or even individuals (or enough individuals working together).

Mmmm, you forgot physical access to targets :-) That is one of their
advantages together with links into national infrastructures and
seemingly endless money. They are much more audacious than "normal"
people.

> There is no doubt that every single security agency in the world has a
> team working on discovering exploitable code in all operating systems.
> It's what they do. Any exploit they find that has been reported is
> probably because some other agency has found it as well so they want to
> stop them using it.

Not only software but hardware too. Most hardware has backdoors which
may not be routinely disclosed to purchasers. The question then arises
if the "official" backdoor is the only one. Difficult to detect if the
logic is coded on a chip.

> The only truly secure machine is one that is at the bottom of a mine
> shaft, turned off and dismantled. :-)

Nope, just protected from public networks like the Internet and from
radio transmissions of all types. Faraday-cage types and 'high-security
rooms' don't have to be buried at the bottom of mines; they exist
everywhere.



-- 
Regards,

Paul.
England, EU.  England's place is in the European Union.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] humor (was Re: OT: systemd Poll)

[Robert Moskowitz]

On 04/16/2017 04:37 PM, Always Learning wrote:

On Thu, 2017-04-13 at 10:39 -0400, Robert Moskowitz wrote:

On 04/12/2017 02:08 PM, m.r...@5-cent.us wrote:

mark "my web pages proudly built in vi!"

And mine on medon.htt-consult.com done with Geany.

Gedit works for me - webpages, PHP, init (with Vi) et cetera.


That means loading gnome.  I use Xfce.  Much better battery life with Xfce.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] humor (was Re: OT: systemd Poll)

[Always Learning]

On Thu, 2017-04-13 at 10:39 -0400, Robert Moskowitz wrote:
> 
> On 04/12/2017 02:08 PM, m.r...@5-cent.us wrote:

> >mark "my web pages proudly built in vi!"

> And mine on medon.htt-consult.com done with Geany.

Gedit works for me - webpages, PHP, init (with Vi) et cetera.



-- 
Regards,

Paul.
England, EU.  England's place is in the European Union.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Help w/Error #14 in grub legacy in CentOS 6.8

[ejm]

Hi all,

I am getting Error #14 from grub version 0.97 when trying to boot for the first 
time into a newly installed partition with Scientific Linux 6.7 and need help 
resolving the error.

The setup:

MacPro with 2 HDs

HD #1:   ESP partition has rEFInd installed and running
 2nd partition: Mac OSX 10.7.5 (lion) installed

HD #2:  1st partition: Centos 6.8   (uses grub version 0.97) 
filesystem = ext4
2nd partition: Debian 8.7   (uses grub 2.0.2 beta).  
filesystem = ext4
3rd partition: Scientific Linux 6.7 (uses grub version 0.97).
filesystem = ext4

The grub.conf in the CentOS partition has the following entries:

title CentOS 6.8 (2.6.32-696.el6.x86_64)
root (hd0,0)
kernel /boot/vmlimuz-2.6.32-696.el6.x86_64 ro 
root=UUID=531c3b86-dc7e-4d14-9505-6df970dc8495 rd_NO_LUKS rd_NO_LVM 
LANG=en_US.UTF-8 rd_no_MD SYSFONT=latarcyrheb=sun16 crashkernel=128M 
KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
initrd /boot/initramfs-2.6.32-696.el6.x86_64.img

title Debian 8.7
root (hd0,1)
chainloader +1

title Scientific Linux 6.7 (Carbon)
root(hd0,2)
kernel /boot/vmlinuz-2.6.32-573.el6.x86_64 ro 
root=UUID=af382492-c826-4cf8-b134-9456fe5c100c
initrd /boot/initramfs-2.6.32-573.el6.x86_64.img
chainloader +1


I can boot fine into the Mac OSX from rEFInd.

When I boot from rEFInd into the CentOS partition I get the Grub version 0.97 
menu list with the 3 OSs listed above.

I can then boot fine into CentOS 6.8 or Debian 8.7 just fine.

I just added Scientific Linux 6.7 (SL) from a downloaded ISO image to the 3rd 
partition.
SL installed fine. The installation itself was done using a PC (AMD64) running 
Windows 7 and the HD connected via USB and a mobile SATA dock.

But using the above grub config for SL I get Error #14.

If I comment-out the kernel and initrd lines in the SL entry I get Error #13.

I confirmed that the kernel and the initramfs files both are in /boot in SL.

I also checked the UUID for the 3rd partition with blkid and that is correct 
too.

If I replace the kernel line for SL with the same one in the SL parititon I 
still get Error #14. The only difference with the full CentOS and SL kernel 
entries are the UUIDs of the partition and the minor version # (696 vs 573).

I haven't seen anything specific to Error #14 in the blog entries I've seen.

Everything I've tried results in either Error #14 or 13.

I do think the SL partition will boot if given the correct grub conf to start 
with.

Any tips or ideas would be greatly appreciated!


Thanks,

--Ed
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Gordon Messmer]

On 04/16/2017 03:53 AM, ken wrote:
And, yes, the exploits also include more than a few against linux.  Go 
to their site and look under vault7.  Or search for "linux" or 
"redhat"... you'll get hundreds of hits.  Here's just one: 
https://wikileaks.org/spyfiles4/documents/FinSpy-3.10-User-Manual.docx 
(If you have only a few seconds to look at it, see page 34.) 



That document appears to describe a remote control application, not an 
exploit.  It's only useful once you have administrative access to the 
system in question.


I won't say that I don't think exploits against Linux systems exist, 
that would be naive.  But, I haven't yet seen any CVEs for GNU/Linux 
systems resulting from the Vault7 leaks.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Pete Biggs]

> Indeed. I think the assertion "OSS is somehow safer because of community
> audit" is a logical fallacy. How would one go about "auditing" in the first
> place?

There are tools to audit source code for problems - OSS is safer
*because* the source is available and can be audited. 

>  Even if the various Intelligence agencies are not injecting
> vulnerabilities then they would certainly be in a strong position to
> discover some of the holes already existing some time before they become
> public.

Yes. And despite what people think, those agencies don't have super
powers. They have tools to help them, and lots of resources, but
nothing out of the ordinary. There is nothing that the NSA can do that
can't be done by other agencies or even individuals (or enough
individuals working together).

There is no doubt that every single security agency in the world has a
team working on discovering exploitable code in all operating systems.
It's what they do. Any exploit they find that has been reported is
probably because some other agency has found it as well so they want to
stop them using it.

> 
> Unless you're operating an air gap network you can be damn sure that 'they'
> can get into your systems if they really want to.

The only truly secure machine is one that is at the bottom of a mine
shaft, turned off and dismantled. :-)

P.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Pete Biggs]

On Sun, 2017-04-16 at 06:53 -0400, ken wrote:
> On 04/15/2017 04:46 AM, Pete Biggs wrote:
> > Not wishing to extend this thread further, but ...
> > 
> > > There are conspiracy theories out there that the NSA is involved with
> > > bringing systemd to Linux so they can have easy access to *"unknown"*
> > > bugs - aka backdoors - to all Linux installations using systemd *[1]*.
> > 
> > They're conspiracy theories, and that's it.
> 
> Hmm.  That's not quite it.  Wikileaks recently posted a trove of docs on 
> CIA exploits.  It was big news.  I'm surprised you missed that.  And, 
> yes, the exploits also include more than a few against linux.

That's not what I said - I said that the security agencies writing
backdoors into systemd was a conspiracy theory. I said later that they
have exploits as part of their toolkit. I'm surprised you missed that
part when you replied to it ...


> Years ago it was revealed that one of the linux developers inserted an 
> exploit into the gcc code which, when the login code was compiled, would 
> give him access to any system running it, effectively every linux 
> system.  This exploit was in the linux code for a long time and was 
> never discovered.  It was revealed only by the developer himself, and 
> only because he was retiring.  Point is: Code is often complex, 
> especially that written in C (or C++ and others), so much so that an 
> exploit can be written into it and not discovered for a long time, or 
> ever.  This is yet another argument against systemd: it would be much 
> easier to hide an exploit in it than in a handful of bash scripts.

Perhaps bash is exploitable - designed to hide the malicious code put
into the init.d scripts by the NSA.

P.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Simple OCSP server ??

[Robert Moskowitz]

What about the pki package that comes with Centos?

pki-server and pki-ca?

On 04/16/2017 11:54 AM, Alice Wonder wrote:

Oh I don't know, their github works.

However it seems that it isn't able to deal with more than one ocsp 
signing key.


On 04/16/2017 08:40 AM, Robert Moskowitz wrote:



On 04/14/2017 10:41 PM, Alice Wonder wrote:

https://www.openca.org/ might fit my needs.


their Centos repo does not exist, it seems?



On 04/14/2017 06:29 PM, Alice Wonder wrote:

Hello list,

I'm contemplating running my own CA to implement the new proposed ISP
for validation of S/MIME certificates via DANE.

I already use self-signed for my MX servers (with 3 1 1 dane 
records on

TCP port 25) but I don't want to use self-signed for S/MIME for user
specific x.509 certs because

A) That's potentially a lot of DNS records
B) That requires a hash of the e-mail addresses in DNS

Instead, I will be using a wildcard in DNS with an intermediary that
signs the user x.509 certificates.

Using an intermediary to sign their certificates though means I can't
just revoke their certificates by removing the DNS certificate, I'll
need to provide an OCSP server for when one of their private keys gets
compromised.

I found
https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Deploy_and_Install_Guide/install-oscp.html 



but it looks like that is intended for enterprise, more complex than I
need.

Anyone know of a good simple script for providing OCSP ??

-=-

Not relevant to question but just important for me to note, I will 
*not*
be asking people to install my root certificate in their e-mail 
clients.

I think it is a bad practice to get users in the habit of installing
root certificates.

I think the PKI system has way way way to many root certificates as it
is. I want a world where DANE validates most certificates, and only a
few root certificates are needed for things like banks where EV
certificates are a must.

DANE as a way to validate S/MIME I think will be a godsend to e-mail
security, I hope clients implement it.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Simple OCSP server ??

[Alice Wonder]

Oh I don't know, their github works.

However it seems that it isn't able to deal with more than one ocsp 
signing key.


On 04/16/2017 08:40 AM, Robert Moskowitz wrote:



On 04/14/2017 10:41 PM, Alice Wonder wrote:

https://www.openca.org/ might fit my needs.


their Centos repo does not exist, it seems?



On 04/14/2017 06:29 PM, Alice Wonder wrote:

Hello list,

I'm contemplating running my own CA to implement the new proposed ISP
for validation of S/MIME certificates via DANE.

I already use self-signed for my MX servers (with 3 1 1 dane records on
TCP port 25) but I don't want to use self-signed for S/MIME for user
specific x.509 certs because

A) That's potentially a lot of DNS records
B) That requires a hash of the e-mail addresses in DNS

Instead, I will be using a wildcard in DNS with an intermediary that
signs the user x.509 certificates.

Using an intermediary to sign their certificates though means I can't
just revoke their certificates by removing the DNS certificate, I'll
need to provide an OCSP server for when one of their private keys gets
compromised.

I found
https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Deploy_and_Install_Guide/install-oscp.html

but it looks like that is intended for enterprise, more complex than I
need.

Anyone know of a good simple script for providing OCSP ??

-=-

Not relevant to question but just important for me to note, I will *not*
be asking people to install my root certificate in their e-mail clients.
I think it is a bad practice to get users in the habit of installing
root certificates.

I think the PKI system has way way way to many root certificates as it
is. I want a world where DANE validates most certificates, and only a
few root certificates are needed for things like banks where EV
certificates are a must.

DANE as a way to validate S/MIME I think will be a godsend to e-mail
security, I hope clients implement it.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Simple OCSP server ??

[Robert Moskowitz]

On 04/14/2017 10:41 PM, Alice Wonder wrote:

https://www.openca.org/ might fit my needs.


their Centos repo does not exist, it seems?



On 04/14/2017 06:29 PM, Alice Wonder wrote:

Hello list,

I'm contemplating running my own CA to implement the new proposed ISP
for validation of S/MIME certificates via DANE.

I already use self-signed for my MX servers (with 3 1 1 dane records on
TCP port 25) but I don't want to use self-signed for S/MIME for user
specific x.509 certs because

A) That's potentially a lot of DNS records
B) That requires a hash of the e-mail addresses in DNS

Instead, I will be using a wildcard in DNS with an intermediary that
signs the user x.509 certificates.

Using an intermediary to sign their certificates though means I can't
just revoke their certificates by removing the DNS certificate, I'll
need to provide an OCSP server for when one of their private keys gets
compromised.

I found
https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Deploy_and_Install_Guide/install-oscp.html 


but it looks like that is intended for enterprise, more complex than I
need.

Anyone know of a good simple script for providing OCSP ??

-=-

Not relevant to question but just important for me to note, I will *not*
be asking people to install my root certificate in their e-mail clients.
I think it is a bad practice to get users in the habit of installing
root certificates.

I think the PKI system has way way way to many root certificates as it
is. I want a world where DANE validates most certificates, and only a
few root certificates are needed for things like banks where EV
certificates are a must.

DANE as a way to validate S/MIME I think will be a godsend to e-mail
security, I hope clients implement it.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Alice Wonder]

On 04/16/2017 06:51 AM, Andrew Holway wrote:


There is no doubt that most security agencies have a long list of zero-

day exploits in their toolbox - I would hazard to suggest that they
wouldn't be doing their job if they didn't! But I seriously doubt they
would commission exploitable code in something that is openly
auditable.

P.



P., I used to think that too... indeed, I was thoroughly convinced of it.
But reality changed my mind.



Indeed. I think the assertion "OSS is somehow safer because of community
audit" is a logical fallacy. How would one go about "auditing" in the first
place? Even if the various Intelligence agencies are not injecting
vulnerabilities then they would certainly be in a strong position to
discover some of the holes already existing some time before they become
public.


I'm more worried about cloud services and the large number of root 
certificates that software trusts by default.


That's where a lot of the hacks are going to happen, and AFAIK the only 
defense against it is DNSSEC + DANE which very few zones actually utilize.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Andrew Holway]

>
> There is no doubt that most security agencies have a long list of zero-
>> day exploits in their toolbox - I would hazard to suggest that they
>> wouldn't be doing their job if they didn't! But I seriously doubt they
>> would commission exploitable code in something that is openly
>> auditable.
>>
>> P.
>>
>
> P., I used to think that too... indeed, I was thoroughly convinced of it.
> But reality changed my mind.


Indeed. I think the assertion "OSS is somehow safer because of community
audit" is a logical fallacy. How would one go about "auditing" in the first
place? Even if the various Intelligence agencies are not injecting
vulnerabilities then they would certainly be in a strong position to
discover some of the holes already existing some time before they become
public.

Unless you're operating an air gap network you can be damn sure that 'they'
can get into your systems if they really want to.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Jonathan Billings]

On Apr 16, 2017, at 6:53 AM, ken  wrote:
> Years ago it was revealed that one of the linux developers inserted an 
> exploit into the gcc code which, when the login code was compiled, would give 
> him access to any system running it, effectively every linux system.  This 
> exploit was in the linux code for a long time and was never discovered.  It 
> was revealed only by the developer himself, and only because he was retiring. 
>  Point is: Code is often complex, especially that written in C (or C++ and 
> others), so much so that an exploit can be written into it and not discovered 
> for a long time, or ever. This is yet another argument against systemd: it 
> would be much easier to hide an exploit in it than in a handful of bash 
> scripts.


When you say “one of the linux developers”, you mean Ken Thompson?

http://wiki.c2.com/?TheKenThompsonHack 

This story predates Linux, and describes a problem with any potential software. 
 

You realize ‘bash’ could be just as malicious as systemd in this scenario?  Are 
you meticulously going through *it’s* source code in your version of the world? 
 Note:  bash is not written in bash.

--
Jonathan Billings 


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[ken]

On 04/15/2017 04:46 AM, Pete Biggs wrote:

Not wishing to extend this thread further, but ...


There are conspiracy theories out there that the NSA is involved with
bringing systemd to Linux so they can have easy access to *"unknown"*
bugs - aka backdoors - to all Linux installations using systemd *[1]*.

They're conspiracy theories, and that's it.


Hmm.  That's not quite it.  Wikileaks recently posted a trove of docs on 
CIA exploits.  It was big news.  I'm surprised you missed that.  And, 
yes, the exploits also include more than a few against linux.  Go to 
their site and look under vault7.  Or search for "linux" or "redhat"... 
you'll get hundreds of hits.  Here's just one: 
https://wikileaks.org/spyfiles4/documents/FinSpy-3.10-User-Manual.docx 
(If you have only a few seconds to look at it, see page 34.)




The bottom line is that in
general people don't like not understanding things and when they come
across something they don't understand they create a mythology around
those things to rationalise their non-understanding.


True, but that "mansplanation" can point in a lot of ways, including at 
Pollyanna.





Systemd is complex; it's implementation was badly handled on a social
level. Nevertheless it is open source. It is highly unlikely that the
NSA, or any other agency, would risk putting in backdoors to code that
could be audited by Joe "random hacker" Blogs, let alone that might be
discovered by hostile agencies.


Years ago it was revealed that one of the linux developers inserted an 
exploit into the gcc code which, when the login code was compiled, would 
give him access to any system running it, effectively every linux 
system.  This exploit was in the linux code for a long time and was 
never discovered.  It was revealed only by the developer himself, and 
only because he was retiring.  Point is: Code is often complex, 
especially that written in C (or C++ and others), so much so that an 
exploit can be written into it and not discovered for a long time, or 
ever.  This is yet another argument against systemd: it would be much 
easier to hide an exploit in it than in a handful of bash scripts.



There is no doubt that most security agencies have a long list of zero-
day exploits in their toolbox - I would hazard to suggest that they
wouldn't be doing their job if they didn't! But I seriously doubt they
would commission exploitable code in something that is openly
auditable.

P.


P., I used to think that too... indeed, I was thoroughly convinced of 
it.  But reality changed my mind.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos