Re: [gentoo-user] Re: Linux USB security holes.

[J. Roeleveld]

On Wednesday, November 8, 2017 8:35:37 PM CET Ian Zimmerman wrote:
> On 2017-11-08 05:53, J. Roeleveld wrote:
> > From what I read, you need physical access.
> 
> According to Solar, for whom I have developed great respect, this is not
> necessarily so:
> 
> http://www.openwall.com/lists/oss-security/2017/11/08/5

I stand corrected. Forgot about this possible avenue. But this will still 
require the person already has access to the system.
I think for most users with just a personal desktop, this is less likely.

It does bring another possible access, most servers have iKVM/IPMI systems 
installed for remote management. Those also allow USB devices to be connected 
over network. I would, however, class access to these parts of the system as 
"physical" access.

--
Joost

[gentoo-user] Re: Systemd

[Nikos Chantziaras]

On 05/11/17 00:02, Canek Peláez Valdés wrote:
On Sat, Nov 4, 2017 at 12:17 PM, Nikos Chantziaras 
 > The only problem I have with systemd is that it's unable 
to reliably restore the ALSA mixer volumes/settings on startup. It fails 
50% of the time. Which is very annoying, but not the end of the world.


Do you have PulseAudio installed? What's the output of 'systemctl status 
alsa-restore.service'? Do you have /var/lib under a "special" (RAID, 
LUKS, whatever) partition?


Yes, I'm using PulseAudio.

The status output is:

$ systemctl status alsa-restore.service
● alsa-restore.service - Save/Restore Sound Card State
   Loaded: loaded (/lib/systemd/system/alsa-restore.service; static; 
vendor preset: disabled)

   Active: active (exited) since Wed 2017-11-08 23:26:55 EET; 14min ago
  Process: 221 ExecStart=/usr/sbin/alsactl restore (code=exited, 
status=0/SUCCESS)

 Main PID: 221 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/alsa-restore.service

Nov 08 23:26:54 gentoopc systemd[1]: Starting Save/Restore Sound Card 
State...

Nov 08 23:26:55 gentoopc systemd[1]: Started Save/Restore Sound Card State.


No special mounts. Everything is a single partition.

[gentoo-user] Re: Systemd

[Nikos Chantziaras]

On 04/11/17 21:23, Rich Freeman wrote:

On Sat, Nov 4, 2017 at 2:17 PM, Nikos Chantziaras  wrote:

[...] The only problem I have with systemd is that it's unable to
reliably restore the ALSA mixer volumes/settings on startup. It fails 50% of
the time. Which is very annoying, but not the end of the world.


Out of curiosity - are you using alsa-state or alsa-restore?
Apparently alsa provides two different ways of preserving state.  You
might consider switching them (which is triggered by the existence of
/etc/alsa/state-daemon.conf - but it might have some other
requirements which I didn't bother to check on).


alsa-restore. It claims to do exactly what I want, run:

  /usr/sbin/alsactl restore

at startup.



With any save/restore tool like these I always keep a copy of the
state somewhere where it doesn't get overwritten at shutdown if I have
a complex configuration.
Well, the thing is that the state is not getting overwritten. When 
during boot systemd fails to restore the volumes, the state is still 
fine and I can manually run:


  /usr/sbin/alsactl restore

and restore the volumes. This sounds like some sort of race condition 
where something else is calling "alsactl init", so sometimes "restore" 
happens after "init", which results in my volumes getting restores, and 
sometimes "init" happens after "restore", which gives me default volume 
levels.

Re: [gentoo-user] Linux USB security holes.

[Alan McKinnon]

On 08/11/2017 07:08, Dale wrote:
> Howdy,
> 
> I ran up on this link.  Is there any truth to it and should any of us
> Gentooers be worried about it?
> 
> http://www.theregister.co.uk/2017/11/07/linux_usb_security_bugs/ 
> 
> Isn't Linux supposed to be more secure than this??



I would say the real problem is USB itself.

What is USB after all? It's a way of sticking any old random thing into
a socket and getting the computer to magically do stuff. So if the
system software then goes ahead and does stuff, it's only really
operating as designed and as spec'ed right?

Yes, those 40 holes are probably all true and quite possibly all
exploitable, and they should also be fixed. But the real problem is that
USB even exists at all.

btw, when you say "Isn't Linux supposed to be more secure than this??"
the answer is a resounding NO

The Linux=safe, Windows=notsafe delusion comes from the 90s when Windows
had no real security features at all, or even any realistic ways to
limit and control access. Linux had a Unix-style userland and kernel, so
you automatically got multi-user/multi-process with per-user
permissions. That alone, by itself, is probably the largest single
security advance in all of computing history. Everything else is icing.

There is nothing in Unix really that is "secure by design", and all von
Neumann machines are actually insecure by design


-- 
Alan McKinnon
alan.mckin...@gmail.com

[gentoo-user] Re: Linux USB security holes.

[Ian Zimmerman]

On 2017-11-08 05:53, J. Roeleveld wrote:

> From what I read, you need physical access.

According to Solar, for whom I have developed great respect, this is not
necessarily so:

http://www.openwall.com/lists/oss-security/2017/11/08/5

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

[gentoo-user] Re: Linux USB security holes.

[Grant Edwards]

On 2017-11-08, R0b0t1  wrote:
> On Tue, Nov 7, 2017 at 11:08 PM, Dale  wrote:
>> Howdy,
>>
>> I ran up on this link.  Is there any truth to it and should any of us
>> Gentooers be worried about it?
>>
>> http://www.theregister.co.uk/2017/11/07/linux_usb_security_bugs/
>>
>> Isn't Linux supposed to be more secure than this??
>>
>
> In theory. There was no comment on the existence of such bugs in the
> Windows driver stack, but they likely exist. However, note:
>
> "The impact is quite limited, all the bugs require physical access to
> trigger," said Konovalov. "Most of them are denial-of-service, except
> for a few that might be potentially exploitable to execute code in the
> kernel."

Expecting a machine to be immune from DoS attacks by somebody who is
allowed to touch the machine is indeed delusion on a pretty grand
scale.  Expecting a machine to be immune to other non-DoS attacks when
they can touch the machine is moderately deluded.

-- 
Grant Edwards   grant.b.edwardsYow! Don't hit me!!  I'm in
  at   the Twilight Zone!!!
  gmail.com

Re: [gentoo-user] Linux USB security holes.

[Martin DiViaio]

 There's an old saying: The only secure computer is one that is locked in a 
room, unplugged. Then again, that computer is only as secure as the lock on the 
door.


On Wednesday, November 8, 2017, 1:48:43 AM EST, R0b0t1  
wrote:  
 
 On Wed, Nov 8, 2017 at 12:10 AM, R0b0t1  wrote:
> On Wed, Nov 8, 2017 at 12:02 AM, Dale  wrote:
>> Dale wrote:
>>> Howdy,
>>>
>>> I ran up on this link.  Is there any truth to it and should any of us
>>> Gentooers be worried about it?
>>>
>>> http://www.theregister.co.uk/2017/11/07/linux_usb_security_bugs/
>>>
>>> Isn't Linux supposed to be more secure than this??
>>>
>>> Dale
>>>
>>> :-)  :-)
>>>
>>
>>
>> To reply to all that posted so far.  I did see that it requires physical
>> access, like a lot of other things.  Once a person has physical access,
>> there are a number of things that can go wrong.
>>
>> It does seem to be one of those things that while possible, has anyone
>> been able to do it in the real world and even without physical access?
>> Odds are, no.
>>
>
> The most widely publicized example is STUXNET. There are also reports
> that malicious USB keys with driver-level exploits are sometimes used
> for industrial espionage.
>
> The key point being that in either case, someone is spending a lot of
> money to research and set up a plausible attack.
>
>> Still, all things considered, Linux is pretty secure.  BSD is more
>> secure from what I've read but Linux is better than windoze.
>>
>> Dale
>>
>> :-)  :-)
>>

I suppose I should add that once the basic work has been done for an
exploit like this it will have great reproducibility. But at that
level you are (usually) talking about very well funded actors, and one
should also be worried about controller-level exploits that would be
much harder to discover from an operating system.

If you can't surround your computer with trustworthy armed guards,
assume you suffer from a serious vulnerability based on the
preliminary work the article is talking about.

Rainbows and Sunshine,
    R0b0t1