Re: Embarrassing security bug in systemd

[David Baron]

On יום רביעי, 6 בדצמבר 2017 22:52:17 IST Urs Thuermann wrote:
> Yesterday, my 10 years old son logged into my laptop running Debian
> jessie using his account, and curiously asked if he is allowed to try
> the /sbin/reboot command.  Knowing I have a Linux system as opposed to
> some crappy Win machine, I replied "sure, go ahead and try".  Seconds
> later I was completely shocked when the machine actually rebooted...
> 
> Of course, my son doesn't have any special privileges, no entry in
> /etc/sudoers, etc.  But then I see
> 
> $ ls -l /sbin/reboot
> lrwxrwxrwx 1 root root 14 Apr  8  2017 /sbin/reboot -> /bin/systemctl
> $ ls -l /bin/systemctl
> -rwxr-xr-x 1 root root 538904 Apr  8  2017 /bin/systemctl
> $ dpkg -S /bin/systemctl
> systemd: /bin/systemctl
> 
> The /bin/systemctl binary is not suid root, so I assume[1] it
> communicates to systemd which then reboots the machine without
> checking what user the request comes from.
> 
> I wonder how can such a severe bug make it into a Debian stable
> distribution?  And is this just an insane default setting on Debian's
> side or is it yet another instance of brain-dead systemd behavior?
> 
> Searching the man pages I couldn't find a way to fix this.  How can
> that be stopped?
> 
> [1] Of course, this is not docuemented in systemctl(1) as usual with
> systemd.  Also, according to the man page, systemctl must be
> called with a "COMMAND" argument which /sbin/reboot doesn't do.
> Obviously, systemctl looks at the name it was called and somehow
> uses that as command.  The admin shall guess about this.
> 
> 
> urs

I find I need to use "sudo" to shutdown or reboot. That is using those 
(pseudo?) commands. Maybe their scripts check before going to sysemctl

Re: Embarrassing security bug in systemd

[Eric S Fraga]

On Wednesday,  6 Dec 2017 at 22:52, Urs Thuermann wrote:
> Yesterday, my 10 years old son logged into my laptop running Debian
> jessie using his account, and curiously asked if he is allowed to try
> the /sbin/reboot command.

Security issues etc. aside, I love the fact that your 10 year old is
asking such a question!
-- 
Eric S Fraga via Emacs 27.0.50, org 9.1.4


signature.asc
Description: PGP signature

Re: Embarrassing security bug in systemd

[Eric S Fraga]

On Wednesday,  6 Dec 2017 at 20:21, Nicholas Geovanis wrote:
> As a former system admin for a university's 370/158 (yes, in the
> Jurassic), all I can say is, wow. That really wouldn't work in an
> American university (big surprise there...). None of that stuff was
> anywhere near a normal human being where I worked.

Yeah, I remember the big red button on the main console on our Amdahl
470.  Very tempting... :-) but definitely not user accessible.

-- 
Eric S Fraga via Emacs 27.0.50, org 9.1.4


signature.asc
Description: PGP signature

Re: Embarrassing security bug in systemd

[deloptes]

Roberto C. Sánchez wrote:

> Then I upgraded, got systemd and it turns out that
> my configuration has been silently broken for a very long time.

to prevent this, keep a list with your customizations and use it as check
list after upgrade

I also see nothing wrong when someone that could press the halt button, can
also run reboot. On the other hand a lot of us decided against systemd (at
least as init daemon: there was a long discussion not that long ago here)

So here it says

$  /sbin/reboot
reboot: must be superuser.


regards

Re: BIOS Can Not Find Disk

[David Christensen]

On 12/05/17 15:18, Pascal Hambourg wrote:

Le 05/12/2017 à 06:55, David Christensen a écrit :
4.  The firmware finds the first GPT partition and file system, which 
look "right" for EFI boot images.


No.

5.  The firmware reads this file system and finds only one file, which 
it loads and runs (starting GRUB):


 /EFI/debian/grubx64.efi


No.

(If there were more than one choice, my guess is that I'd have to 
pre-select one in the CMOS setup, or perhaps have to select one from a 
menu at the end of POST?)


No.

First, a compliant UEFI firmware should look up its EFI boot variables 
and try each boot entry Boot* in the order defined in the BootOrder 
variable. The text description associated to theses entries is usually 
displayed in the EFI boot menu. If no entry is defined or works, then 
the firmware should look for a partition with the "EFI system partition" 
type GUID and look for an /EFI/Boot/bootx64.efi file (default path used 
on removable devices).


GRUB can be installed in such a path with

grub-install --removable

6.  GRUB finds the second GPT partition and file system, which looks 
"right" for GRUB, reads the file system, locates the appropriate files 
(notably /boot/grub/grub.cfg), and boots the system.


When /boot/grub is in a plain partition on the same drive as GRUB's core 
image (grubx64.efi here), the partition number is hardcoded in the core 
image.


Again -- are there any other commands I should run that readers might 
find interesting?


You can print the EFI boot variables with

efibootmgr -v


root@debian:~# efibootmgr -v
Timeout: 1 seconds
BootOrder: 0001,,000B,000D,000E
Boot* Windows Boot Manager 
HD(1,GPT,b1ed9b97-3b16-4838-8b46-3978e905fdd9,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a
Boot0001* debian 
HD(1,GPT,c89f1523-fff6-45d1-abbe-b2eaaa0216e0,0x800,0x10)/File(\EFI\debian\grubx64.efi)

Boot000B* CD/DVD Drive  BBS(CDROM,,0x0)P3: HL-DT-ST BD-RE  WH14NS40  .
Boot000D* Network Card  BBS(Network,,0x0)IBA GE Slot 00C8 v1395.
Boot000E* Hard DriveBBS(HD,,0x0)P0: INTEL SSDSC2CW060A3.


Boot -- there is no Windows drive in this machine.


Boot0001 -- corresponds to the first GPT partition on the SSD that is in 
the machine:


root@debian:~# blkid /dev/sda1
/dev/sda1: UUID="8F67-ADA4" TYPE="vfat" 
PARTUUID="c89f1523-fff6-45d1-abbe-b2eaaa0216e0"


root@debian:~# mount /dev/sda1 /mnt

root@debian:~# ls -l /mnt/EFI/debian/grubx64.efi
-rwx-- 1 root root 121856 Dec  4 20:23 /mnt/EFI/debian/grubx64.efi


Boot000B -- corresponds to my optical drive.


Boot000D -- corresponds to my network interface.


Boot000E -- corresponds to an SSD (with Debian Stretch BIOS/MBR) that 
was in the machine in the past, but was not installed when I installed 
Debian UEFI/GPT and currently is not installed.



STFW I see:

http://www.uefi.org/

http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf

2,706 pages -- that's going to take a while to read...


David

Re: USB camera.

[peter]

*   From: Reco 
*   Date: Fri, 3 Nov 2017 18:11:57 +0300
> This one does, at least right now it did with mpv.
> lsusb tells me that it's:
> 
> 058f:5608 Alcor Micro Corp

*   From: deloptes 
*   Date: Fri, 03 Nov 2017 18:04:40 +0100
> ID 0471:2036 Philips (or NXP) Webcam SPC1030NC
> 
> works very well - already ~10y in use

OK, thanks.

The local consignment shop currently has these 3 cameras in stock.

Logitech M/N: V-UH9,   P/N: 861078-0030
Logitech M/N: V-UAV36, P/N: 861200-
Logitech M/N: V-U0006, P/N: 860-000177, PID: LZ944BN

Can anyone confirm one working in Debian 9?

Thanks, ... Peter E.



-- 

123456789 123456789 123456789 123456789 123456789 123456789 123456789
Tel: +1 360 639 0202  Pender Is.: +1 250 629 3757
http://easthope.ca/Peter.html  Bcc: peter at easthope. ca

Re: Embarrassing security bug in systemd

[Roberto C . Sánchez]

On Wed, Dec 06, 2017 at 06:56:12PM -0500, Michael Stone wrote:
> 
> Side note: historically, people have always wanted to be able to reboot or
> shutdown the system they were sitting in front of. This led to a lot of
> really horrible solutions, like a bunch of setuid helper programs and
> one-off site specific hacks. Having this functionality standardized in one
> place is a net win for security, especially since there's also now a single
> standarized way to change the privileges.
> 
I don't necessarily disagree that having it centralized is a win.  I do,
however, think that it should have earned a mention in the release
notes.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Embarrassing security bug in systemd

[Roberto C . Sánchez]

On Wed, Dec 06, 2017 at 10:48:11PM +, Brian wrote:
> On Wed 06 Dec 2017 at 22:52:17 +0100, Urs Thuermann wrote:
> 
> > Yesterday, my 10 years old son logged into my laptop running Debian
> > jessie using his account, and curiously asked if he is allowed to try
> > the /sbin/reboot command.  Knowing I have a Linux system as opposed to
> > some crappy Win machine, I replied "sure, go ahead and try".  Seconds
> > later I was completely shocked when the machine actually rebooted...
> > 
> > Of course, my son doesn't have any special privileges, no entry in
> > /etc/sudoers, etc.  But then I see
> 
> He is privileged because he has physical access to the machine.
> 
Not necessarily.  It is falacious to assume that someone logging in via
display manager or TTY has physical access.

-- 
Roberto C. Sánchez

Re: Embarrassing security bug in systemd

[Roberto C . Sánchez]

On Thu, Dec 07, 2017 at 12:18:30PM +1300, Ben Caradoc-Davies wrote:
> On 07/12/17 11:30, Roberto C. Sánchez wrote:
> > I too consider this a rather serious bug.  However, I do not see any
> > evidence in the BTS [0] that such a bug has yet been reported against
> > systemd.
> 
> Not a bug. We can file this one alongside "console user has access to
> keyboard". Where did I out that CVE?
> 
Actually not.  In my case I use GDM.  I have a configuration directive
in /etc/gdm3/greeter.dconf-defaults as follows:

disable-restart-buttons=true

Since I have decided to let GDM manage graphical login and otherwise
depended on the fact that in order to reboot from a TTY or remote
session root permissions are required, I find systemd's behavior to be
buggy.

> Five seconds of Googling informed me that systemd-inhibit can be used to
> prevent shutdown. If you are absolutely sure that you want to wreck the
> well-thought-out privileges for console users, craft a polkit rule. If you
> only want to avoid accidents, install molly-guard.
> 
This is not something that I should have to Google.  I previously had a
working configuration that prevented halting or rebooting the system by
all non-root users.  Then I upgraded, got systemd and it turns out that
my configuration has been silently broken for a very long time.  The
fact that systemd does not respect conventions (i.e., must be root to
halt/reboot) or established configuration directives (i.e., in display
managers) should have at the very least been included in the release
notes.

This is the kind of nonsense that makes people dislike systemd.  The
priviliges for console users were already well thought out *BEFORE*
systemd, then systemd came along and wrecked it.  This is certainly not
the only example where systemd does something like this.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Embarrassing security bug in systemd

[Nicholas Geovanis]

On Wed, Dec 6, 2017 at 6:49 PM, David Wright 
wrote:

> On Wed 06 Dec 2017 at 15:25:10 (-0800), James H. H. Lampert wrote:
>
> > Now, now, you walk up to the physical console on an AS/400, you're
> > not going to be able to do a PWRDWNSYS from a sign-on screen, nor
> > can do it if signed on as a user who doesn't have sufficient
> > authority to do a PWRDWNSYS. And you might be physically locked out
> > of the front panel. It's even possible that you might be physically
> > interdicted from unplugging the box, or shutting it down from the
> > circuit breaker panel.
>
> With the Cambridge University computing service in the days of the
> 370/165, the cut-off switch was high on the wall in the "cafeteria"
> area (self-service card reader and line printer) which was open to
> users 24 hours a day.


As a former system admin for a university's 370/158 (yes, in the Jurassic),
all I can
say is, wow. That really wouldn't work in an American university (big
surprise there...).
None of that stuff was anywhere near a normal human being where I worked.


> > Not every OS assumes by default that anybody with physical access to
> > the hardware also has the authority to shut it down.
>
> I didn't know we were talking about authority. One of the pastimes
> of kids in rough neighbourhoods is to pull the Engine Stop lever
> while a bus is picking up passengers.


And here they steal the conductors' keys on the subway and open the doors
in mid-trip.
So, we don't have conductors anymore, not for years. That's the American
solution.

But no one has picked-up the man's point: We deploy these machines as
servers, thousands
of them. This is desktop stuff that doesn't belong there, has no function
there. If we're going
to deploy these machines, why can't the manufacturers get a real, solid
clue about physical
security of the hardware? If the mainframes could do it 35 years ago why
can't it be done
today with smaller, discrete servers? Answer: It can be, but the
manufacturers value their
profit margin over your safety.

And, well, it must be said: An AS/400 is no mainframe, it's a miniSorry
dude ;-)

Re: Embarrassing security bug in systemd

[Dejan Jocic]

On 07-12-17, Michael Biebl wrote:
> 
> As has already been mentioned, active, local users can shutdown/reboot
> the system without requiring a password. This is intended behaviour (for
> the reasons already mentioned) and can indeed be overridden by custom
> polkit rules.
> 

Is there anywhere in Debian documentation example, or explanation how to
override anything with custom polkit rules? I could not find it, but
guess that it is possible that somehow I've missed it.



> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 

Re: Embarrassing security bug in systemd

[David Wright]

On Wed 06 Dec 2017 at 15:25:10 (-0800), James H. H. Lampert wrote:
> On 12/6/17, 2:53 PM, Michael Lange wrote:
> >uh, I guess you ought to have used your time to check your machine and
> >read some docs instead of figuring out how to best insult the debian
> >developers ;)
> >(scnr)
> 
> Now, now, you walk up to the physical console on an AS/400, you're
> not going to be able to do a PWRDWNSYS from a sign-on screen, nor
> can do it if signed on as a user who doesn't have sufficient
> authority to do a PWRDWNSYS. And you might be physically locked out
> of the front panel. It's even possible that you might be physically
> interdicted from unplugging the box, or shutting it down from the
> circuit breaker panel.

I can't speak for your jurisdiction, but typically you can shut down
a machine room without access to the room itself. I guess one reason
for this is that the halon fire suppression would kill you on entry.
With the Cambridge University computing service in the days of the
370/165, the cut-off switch was high on the wall in the "cafeteria"
area (self-service card reader and line printer) which was open to
users 24 hours a day.

> Not every OS assumes by default that anybody with physical access to
> the hardware also has the authority to shut it down.

I didn't know we were talking about authority. One of the pastimes
of kids in rough neighbourhoods is to pull the Engine Stop lever
while a bus is picking up passengers.

> (And likewise, accounts, including QSECOFR [the closest OS/400
> equivalent to root] can be restricted to certain physical
> terminals.)

Cheers,
David.

Re: Embarrassing security bug in systemd

[Michael Stone]

On Wed, Dec 06, 2017 at 03:25:10PM -0800, James H. H. Lampert wrote:
Now, now, you walk up to the physical console on an AS/400, you're not 
going to be able to do a PWRDWNSYS from a sign-on screen, nor can do 
it if signed on as a user who doesn't have sufficient authority to do 
a PWRDWNSYS. And you might be physically locked out of the front 
panel. It's even possible that you might be physically interdicted 
from unplugging the box, or shutting it down from the circuit breaker 
panel.


Not every OS assumes by default that anybody with physical access to 
the hardware also has the authority to shut it down.


In the extremely unlikely event that you have your debian system
configured with that level of physical access control, you can adjust 
the power/reboot permissions to suit your preferences. For most other 
users, the defaults are reasonable.


The main realistic use case of a different default is kiosk systems, 
where changing the privileges given to locally logged in users is just 
one of the steps that should be taken. In general, defaults are chosen 
to be useful for the largest set of users. 

Side note: historically, people have always wanted to be able to reboot 
or shutdown the system they were sitting in front of. This led to a lot 
of really horrible solutions, like a bunch of setuid helper programs and 
one-off site specific hacks. Having this functionality standardized in 
one place is a net win for security, especially since there's also now a 
single standarized way to change the privileges.


Mike Stone

Re: Embarrassing security bug in systemd

[David Wright]

On Wed 06 Dec 2017 at 22:52:17 (+0100), Urs Thuermann wrote:
> Yesterday, my 10 years old son logged into my laptop running Debian
> jessie using his account, and curiously asked if he is allowed to try
> the /sbin/reboot command.  Knowing I have a Linux system as opposed to
> some crappy Win machine, I replied "sure, go ahead and try".  Seconds
> later I was completely shocked when the machine actually rebooted...

That's a lot of typing! I just type Ctrl-Alt-Backspace Ctrl-Alt-Del
to reboot, or tap the power button to shut down. I've also noticed
that I don't need to type any password to close the lid.
Presumably your son has progressed beyond mischievously holding down
the power button.

Cheers,
David.

Re: Embarrassing security bug in systemd

[Michael Biebl]

Am 06.12.2017 um 23:53 schrieb Michael Lange:
> Hi,
> 
> uh, I guess you ought to have used your time to check your machine and
> read some docs instead of figuring out how to best insult the debian
> developers ;)
> (scnr)
> 
> On 06 Dec 2017 22:52:17 +0100
> Urs Thuermann  wrote:
> 
> (...)
>> I wonder how can such a severe bug make it into a Debian stable
>> distribution?  And is this just an insane default setting on Debian's
>> side or is it yet another instance of brain-dead systemd behavior?
> 
> Maybe I am just a brain-dead loony, but personally I prefer to be able to
> shut down or reboot my system without having to type a password. If you
> do not like this behavior you might have to learn how to define
> polkit rules.

For the interested reader, see
/usr/share/polkit-1/actions/org.freedesktop.login1.policy

org.freedesktop.login1.power-off has the following defaults


  auth_admin_keep
  auth_admin_keep
  yes


As has already been mentioned, active, local users can shutdown/reboot
the system without requiring a password. This is intended behaviour (for
the reasons already mentioned) and can indeed be overridden by custom
polkit rules.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Embarrassing security bug in systemd

[James H. H. Lampert]

On 12/6/17, 2:53 PM, Michael Lange wrote:

uh, I guess you ought to have used your time to check your machine and
read some docs instead of figuring out how to best insult the debian
developers ;)
(scnr)


Now, now, you walk up to the physical console on an AS/400, you're not 
going to be able to do a PWRDWNSYS from a sign-on screen, nor can do it 
if signed on as a user who doesn't have sufficient authority to do a 
PWRDWNSYS. And you might be physically locked out of the front panel. 
It's even possible that you might be physically interdicted from 
unplugging the box, or shutting it down from the circuit breaker panel.


Not every OS assumes by default that anybody with physical access to the 
hardware also has the authority to shut it down.


;-p

(And likewise, accounts, including QSECOFR [the closest OS/400 
equivalent to root] can be restricted to certain physical terminals.)


--
JHHL

Re: Embarrassing security bug in systemd

[Ben Caradoc-Davies]

On 07/12/17 11:30, Roberto C. Sánchez wrote:

I too consider this a rather serious bug.  However, I do not see any
evidence in the BTS [0] that such a bug has yet been reported against
systemd.


Not a bug. We can file this one alongside "console user has access to 
keyboard". Where did I out that CVE?


Five seconds of Googling informed me that systemd-inhibit can be used to 
prevent shutdown. If you are absolutely sure that you want to wreck the 
well-thought-out privileges for console users, craft a polkit rule. If 
you only want to avoid accidents, install molly-guard.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Embarrassing security bug in systemd

[Michael Lange]

Hi,

uh, I guess you ought to have used your time to check your machine and
read some docs instead of figuring out how to best insult the debian
developers ;)
(scnr)

On 06 Dec 2017 22:52:17 +0100
Urs Thuermann  wrote:

(...)
> I wonder how can such a severe bug make it into a Debian stable
> distribution?  And is this just an insane default setting on Debian's
> side or is it yet another instance of brain-dead systemd behavior?

Maybe I am just a brain-dead loony, but personally I prefer to be able to
shut down or reboot my system without having to type a password. If you
do not like this behavior you might have to learn how to define
polkit rules.

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Lots of people drink from the wrong bottle sometimes.
-- Edith Keeler, "The City on the Edge of Forever",
   stardate unknown

Re: Embarrassing security bug in systemd

[Brian]

On Wed 06 Dec 2017 at 22:52:17 +0100, Urs Thuermann wrote:

> Yesterday, my 10 years old son logged into my laptop running Debian
> jessie using his account, and curiously asked if he is allowed to try
> the /sbin/reboot command.  Knowing I have a Linux system as opposed to
> some crappy Win machine, I replied "sure, go ahead and try".  Seconds
> later I was completely shocked when the machine actually rebooted...
> 
> Of course, my son doesn't have any special privileges, no entry in
> /etc/sudoers, etc.  But then I see

He is privileged because he has physical access to the machine.

> 
> $ ls -l /sbin/reboot
> lrwxrwxrwx 1 root root 14 Apr  8  2017 /sbin/reboot -> /bin/systemctl
> $ ls -l /bin/systemctl
> -rwxr-xr-x 1 root root 538904 Apr  8  2017 /bin/systemctl
> $ dpkg -S /bin/systemctl
> systemd: /bin/systemctl
> 
> The /bin/systemctl binary is not suid root, so I assume[1] it
> communicates to systemd which then reboots the machine without
> checking what user the request comes from.
> 
> I wonder how can such a severe bug make it into a Debian stable
> distribution?  And is this just an insane default setting on Debian's
> side or is it yet another instance of brain-dead systemd behavior?

A user with physical access to the machine can press the ON/OFF switch
or pull the plug out or switch to a terminal and do CTL+ALT+DEL. Which
one of these actions is a bug in Debian?
 
> Searching the man pages I couldn't find a way to fix this.  How can
> that be stopped?

A cast-iron solution for stopping a user with physical access to a
machine from powering it off has been sought for ages.

-- 
Brian.

Re: BIOS Can Not Find Disk

[Felix Miata]

Pascal Hambourg composed on 2017-12-06 23:16 (UTC+0100):

> Felix Miata composed:

>> Nothing in that post makes it unambiguous that an MBR (MSDOS) partitioned 
>> disk
>> was not the subject of discussion.

> In the context of a GPT partitioned disk,   

 That context was missing from post you're complaining about.

> anyone else understands
> without any doubt that /dev/sda1 refers to the partition #1 defined in 
> the GPT partition table, not in the protective MBR.

>>> sda1 cannot be a type ee partition. Type ee can exist only in the MBR,
>>> and real partitions sda1, sda2... exist in the GPT table.

>>   The post Dan's quote came from, standing alone, as a whole, was confusion.
>> Absent clear indication of GPT context,

> Please read again the initial post. It contains absolutely clear 
> indication that the disk has a GPT label. 

 When the (long) entire thread is read, it eventually becomes apparent that the
OP switched back and forth between GPT and MBR.

The initial thread post was not relevant to the purpose of my post, which was
intended to clarify meaning of the thread post I replied to standing alone.
Critical in my post is it was addressing exclusively the content of the replied
to post. I wasn't writing exclusively for the benefit the OP or thread readers.
On the contrary, I was writing primarily to the mailing list archive, for those
finding it via web search and trying to understand it entirely based on what it
contained.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Embarrassing security bug in systemd

[Glenn English]

On Wed, Dec 6, 2017 at 9:52 PM, Urs Thuermann  wrote:

> Of course, my son doesn't have any special privileges, no entry in
> /etc/sudoers, etc.  But then I see
>
> $ ls -l /sbin/reboot
> lrwxrwxrwx 1 root root 14 Apr  8  2017 /sbin/reboot -> /bin/systemctl
> $ ls -l /bin/systemctl

Same in Buster...

--
Glenn English

Re: Embarrassing security bug in systemd

[Michael Stone]

On Wed, Dec 06, 2017 at 10:52:17PM +0100, Urs Thuermann wrote:

Yesterday, my 10 years old son logged into my laptop running Debian
jessie using his account, and curiously asked if he is allowed to try
the /sbin/reboot command.  Knowing I have a Linux system as opposed to
some crappy Win machine, I replied "sure, go ahead and try".  Seconds
later I was completely shocked when the machine actually rebooted...


It's a feature. Users at the console can reboot, on the theory that if 
someone's sitting at the laptop they could also just push the power 
button...


If they were logged in remotely, they would not be able to reboot.

Mike Stone

Re: Embarrassing security bug in systemd

[Roberto C . Sánchez]

On Wed, Dec 06, 2017 at 10:52:17PM +0100, Urs Thuermann wrote:
> Yesterday, my 10 years old son logged into my laptop running Debian
> jessie using his account, and curiously asked if he is allowed to try
> the /sbin/reboot command.  Knowing I have a Linux system as opposed to
> some crappy Win machine, I replied "sure, go ahead and try".  Seconds
> later I was completely shocked when the machine actually rebooted...
> 
I just tried this (in a VM) and was shocked to find that it works.

> Of course, my son doesn't have any special privileges, no entry in
> /etc/sudoers, etc.  But then I see
> 
> $ ls -l /sbin/reboot
> lrwxrwxrwx 1 root root 14 Apr  8  2017 /sbin/reboot -> /bin/systemctl
> $ ls -l /bin/systemctl
> -rwxr-xr-x 1 root root 538904 Apr  8  2017 /bin/systemctl
> $ dpkg -S /bin/systemctl
> systemd: /bin/systemctl
> 
Here are the other things in /sbin symlinked to systemctl:

$ ls -l /sbin/ |grep systemctl
lrwxrwxrwx 1 root root14 Jul  5 16:31 halt -> /bin/systemctl
lrwxrwxrwx 1 root root14 Jul  5 16:31 poweroff -> /bin/systemctl
lrwxrwxrwx 1 root root14 Jul  5 16:31 reboot -> /bin/systemctl
lrwxrwxrwx 1 root root14 Jul  5 16:31 runlevel -> /bin/systemctl
lrwxrwxrwx 1 root root14 Jul  5 16:31 shutdown -> /bin/systemctl
lrwxrwxrwx 1 root root14 Jul  5 16:31 telinit -> /bin/systemctl

> The /bin/systemctl binary is not suid root, so I assume[1] it
> communicates to systemd which then reboots the machine without
> checking what user the request comes from.
> 
> I wonder how can such a severe bug make it into a Debian stable
> distribution?  And is this just an insane default setting on Debian's
> side or is it yet another instance of brain-dead systemd behavior?
> 
I too consider this a rather serious bug.  However, I do not see any
evidence in the BTS [0] that such a bug has yet been reported against
systemd.

> Searching the man pages I couldn't find a way to fix this.  How can
> that be stopped?
> 
I wonder the same thing.

Regards,

-Roberto

[0] https://bugs.debian.org/src:systemd

-- 
Roberto C. Sánchez

Re: Embarrassing security bug in systemd

[Ben Caradoc-Davies]

On 07/12/17 10:52, Urs Thuermann wrote:

Yesterday, my 10 years old son logged into my laptop running Debian
jessie using his account, and curiously asked if he is allowed to try
the /sbin/reboot command.  Knowing I have a Linux system as opposed to
some crappy Win machine, I replied "sure, go ahead and try".  Seconds
later I was completely shocked when the machine actually rebooted...


I think that allowing a user logged in at the console to reboot the 
system is the correct behaviour for most desktops, whether via GUI or 
terminal. Special privileges have been granted to console users for as 
long as I can remember, long before systemd, because they have physical 
access to the machine. Console users typically are also permitted to 
mount, unmount, and eject removable media, and have access to audio 
devices. Special configuration is required to remove this functionality 
on kiosks, for example.


Please ask your son to try to reboot while logged remotely with ssh 
(loopback may be equivalent). I know that my local desktop permits 
passwordless shutdown while remote shutdown on another systemd machine 
requires a user password *and* that the user to be in sudoers.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: BIOS Can Not Find Disk

[Pascal Hambourg]

Le 05/12/2017 à 03:33, Felix Miata a écrit :

Pascal Hambourg composed on 2017-12-05 00:41 (UTC+0100):


You're the only one bringing additional confusion.
Nobody but you talked about doing such a stupid thing as removing a type
ee partition. Dan and I only talked about removing the BIOS boot
partition sda1.


  In https://lists.debian.org/debian-user/2017/12/msg00089.html

Following is the entirety of what Dan wrote:

  "Then, to proceed, remove /dev/sda1 partition followed by grub-install?"

Nothing in that post makes it unambiguous that an MBR (MSDOS) partitioned disk
was not the subject of discussion.


In the context of a GPT partitioned disk, anyone else understands 
without any doubt that /dev/sda1 refers to the partition #1 defined in 
the GPT partition table, not in the protective MBR.



sda1 cannot be a type ee partition. Type ee can exist only in the MBR,
and real partitions sda1, sda2... exist in the GPT table.


  The post Dan's quote came from, standing alone, as a whole, was confusion.
Absent clear indication of GPT context,


Please read again the initial post. It contains absolutely clear 
indication that the disk has a GPT label.



the term "BIOS boot partition" is ambiguous.


No it is not. It has a perfecly clear definition, and even an entry in 
Wikipedia : 


 It could easily enough be construed as the 16 bytes at LBA 0 address

01BEh, which in BIOS/MSDOS partitioning context is sda1.


There is no such "BIOS boot" partition type defined in DOS/MBR partition 
types.

Embarrassing security bug in systemd

[Urs Thuermann]

Yesterday, my 10 years old son logged into my laptop running Debian
jessie using his account, and curiously asked if he is allowed to try
the /sbin/reboot command.  Knowing I have a Linux system as opposed to
some crappy Win machine, I replied "sure, go ahead and try".  Seconds
later I was completely shocked when the machine actually rebooted...

Of course, my son doesn't have any special privileges, no entry in
/etc/sudoers, etc.  But then I see

$ ls -l /sbin/reboot
lrwxrwxrwx 1 root root 14 Apr  8  2017 /sbin/reboot -> /bin/systemctl
$ ls -l /bin/systemctl
-rwxr-xr-x 1 root root 538904 Apr  8  2017 /bin/systemctl
$ dpkg -S /bin/systemctl
systemd: /bin/systemctl

The /bin/systemctl binary is not suid root, so I assume[1] it
communicates to systemd which then reboots the machine without
checking what user the request comes from.

I wonder how can such a severe bug make it into a Debian stable
distribution?  And is this just an insane default setting on Debian's
side or is it yet another instance of brain-dead systemd behavior?

Searching the man pages I couldn't find a way to fix this.  How can
that be stopped?

[1] Of course, this is not docuemented in systemctl(1) as usual with
systemd.  Also, according to the man page, systemctl must be
called with a "COMMAND" argument which /sbin/reboot doesn't do.
Obviously, systemctl looks at the name it was called and somehow
uses that as command.  The admin shall guess about this.


urs

Re: Removing old python packages installed with pip

[Urs Thuermann]

deloptes  writes:

> yes it is more or less safe - it depends how you let it install - perhaps
> there is also something under /usr/local/bin

Thanks, I'll do it then.  And yes, there are 3 binaries in
/usr/local/bin from the theano package with the same installation
date, which I will also remove.

urs

Re: Removing old python packages installed with pip

[Urs Thuermann]

Eike Lantzsch  writes:

> On Friday, December 1, 2017 3:24:47 PM -03 Urs Thuermann wrote:
> > On a machine running Debian stretch I have installed python3, which is
> > currently python3.5.  Nothing of python3.4 is present.
> > 
> > But in /usr/local/lib/python3.4/dist-packages/ a number of packages is
> > still installed.  Probably, these have been installed using pip3 when
> > python3.4 was current.
> > 
> > Now, it seems pip3 isn't able to remove packages from that old
> > directory.  Is it safe to just rm -r /usr/local/lib/python3.4?

> If those packages were installed together with the Debian system then 
> deinstall with aptitude or apt remove.

No, as I said, it was (most probably) installed using pip3 when
python3.4 was current in Debian.  Debian packagement doesn't know
about it, so cannot uninstall it.

> If you mix two different package installers the consequence is that one does 
> not know about the other and they can interfere with each other.

No, nothing is mixed.  pip installs in /usr/local, Debian packagement
installs in /usr.

But pip3 formerly installed in /usr/local/lib/python3.4 but now seems
not to know about anymore.  Now it installs in /usr/local/lib/python3.5.
Therefore, pip3 doesn't list and cannot uninstall python packages from
the older /usr/local/lib/python3.4.  Also, python3, which is 3.5
currently, seems not to search that old directory.

I am almost sure that just removing it will be fine, but I wanted to
make sure, that no file of pip3 e.g. in /var or elsewhere still refers
to /usr/local/lib/python3.4.  That's why I asked here.

> On Debian always install packages the "Debian way".

There are Python packages like theano and keras that are not in
Debian.  They can only be installed completely manually or using
pip3.  In both cases they go to /usr/local, of course.

urs

Re: EDA software.

[Fred]

On 12/06/2017 09:57 AM, pe...@easthope.ca wrote:

Hi,

At https://wiki.debian.org/DebianTinker/Desktop#EDA is a list of
packages for electronics design automation.  According to various
documents, Electric, Fritzing and gEDA, at least, can help to create
schematics.  I use librecad but have never used schematic construction
software.  Which of the EDA packages will be a good starting point?
Is any integrated with Librecad?

Thanks,... Peter E.
I recommend xcircuit for schematic capture.  The author Tim Edwards at 
opencircuitdesign.com is very helpful.


Best regards,
Fred Boatwright

Re: EDA software.

[Elimar Riesebieter]

* Joe  [2017-12-06 18:31 +]:

[...]
> I'm not sure what kind of connection with LibreCAD there could be: DXF
> is a much more complex file structure, and I think the most that could
> be done would be to transfer PCB outlines and mounting points. There is
> some provision for component height in PCB, but no easy way to
> manipulate values, and I don't believe LibreCAD can do anything in the
> way of 3D anyway.

kicad seems to be able to im/export dxf format. There are also
existing powerful 3-D libraries [0]. With those implemented you'll
be able to design 3-D pcb's and export them as STEP-214 to pull them
in to a 3-D capable CAD system which is useful to design housings,
complete devices etc. ...

Elimar
[0] http://smisioto.no-ip.org/elettronica/kicad/kicad-en.htm
-- 
  On the keyboard of life you have always
  to keep a finger at the escape key;-)

Re: EDA software.

[John Conover]

pe...@easthope.ca writes:
> 
> At https://wiki.debian.org/DebianTinker/Desktop#EDA is a list of 
> packages for electronics design automation.  According to various 
> documents, Electric, Fritzing and gEDA, at least, can help to create 
> schematics.  I use librecad but have never used schematic construction 
> software.  Which of the EDA packages will be a good starting point?  
> Is any integrated with Librecad?
>

Hi Peter. All the files in gEDA are text files, and its very
extensible.  There is an active community for gEDA; the specialty is
analog design, (although many use it for digital.) Kicad is an
alternative with a larger user base; the specialty is digital
design. Both have mailing list support and are good choices.

Presumably, you want to do schematic capture, (for simulation, PCB
production, etc.) If you are going to do PCB prototyping in house,
gEDA has a slight advantage. If you are outsourcing PCB production,
Kicad has a slight advantage.

gEDA will probably require you to make some component foot prints,
(although there is a library of the most used components,) which is
easy enough. Kicad has a large library of foot prints.

Both have hooks into the common EDA/CAD/CAM programs, (spice, etc.,)
but setting stuff up is a bit of a pain in both cases.

gEDA is user supported, Kicad is supported by CERN.

Suggestion: try both. gEDA is available via apt-get from the Debian
repository. Decide on only one, (either is a good choice.)
Transporting a design back-and-forth between the two systems is
tricky, at best.

John

-- 

John Conover, cono...@rahul.net, http://www.johncon.com/

Re: EDA software.

[Michael Milliman]

I have used several of the choices mentioned. I have settled on gEDA suite
for a couple of times reasons. First, using the proper tool chain, it
integrates with the ngspice and gnucap simulators. It also allows complete
project creation from schematic thru simulation to PC board layout.

It is true that the learning curve is rather steep, but it is well worth
your while to take the time to learn how to use these tools.

73s de WB5VQX

On Dec 6, 2017 12:31, "Joe"  wrote:

On Wed, 06 Dec 2017 08:57:09 -0800
pe...@easthope.ca wrote:

> Hi,
>
> At https://wiki.debian.org/DebianTinker/Desktop#EDA is a list of
> packages for electronics design automation.  According to various
> documents, Electric, Fritzing and gEDA, at least, can help to create
> schematics.  I use librecad but have never used schematic
> construction software.  Which of the EDA packages will be a good
> starting point? Is any integrated with Librecad?
>

I suspect they all have a bit of a learning curve. The gEDA suite is
probably the most difficult, but I haven't tried any alternative, there
were none when I began and I don't really feel like changing horses
now. I suspect it is also the most powerful.

What people like about other systems is the 'integration'. The gEDA
suite is clearly two disparate major tools, with completely different
file structures, but as both are text based, it's not hard to plumb one
into the other. There are a number of command-line utilities, and
scripts and spreadsheets to generate families of parts.

I find I need to make most of the footprints I use, and a lesser number
of schematic symbols: there are libraries, and many user contributions
around the Net, but there are so many hundreds of thousands of parts
that a lot have to be made from scratch, which isn't difficult.

I'm not sure what kind of connection with LibreCAD there could be: DXF
is a much more complex file structure, and I think the most that could
be done would be to transfer PCB outlines and mounting points. There is
some provision for component height in PCB, but no easy way to
manipulate values, and I don't believe LibreCAD can do anything in the
way of 3D anyway.

--
Joe

Re: EDA software.

[Elimar Riesebieter]

* pe...@easthope.ca  [2017-12-06 08:57 -0800]:

> Hi,
> 
> At https://wiki.debian.org/DebianTinker/Desktop#EDA is a list of 
> packages for electronics design automation.  According to various 
> documents, Electric, Fritzing and gEDA, at least, can help to create 
> schematics.  I use librecad but have never used schematic construction 
> software.  Which of the EDA packages will be a good starting point?  
> Is any integrated with Librecad?

I'd give kicad a shot:

apt-cache show kicad

Have a look at http://kicad-pcb.org/ too.

Elimar
-- 
  You cannot propel yourself forward by
  patting yourself on the back.

Re: EDA software.

[Joe]

On Wed, 06 Dec 2017 08:57:09 -0800
pe...@easthope.ca wrote:

> Hi,
> 
> At https://wiki.debian.org/DebianTinker/Desktop#EDA is a list of 
> packages for electronics design automation.  According to various 
> documents, Electric, Fritzing and gEDA, at least, can help to create 
> schematics.  I use librecad but have never used schematic
> construction software.  Which of the EDA packages will be a good
> starting point? Is any integrated with Librecad?
> 

I suspect they all have a bit of a learning curve. The gEDA suite is
probably the most difficult, but I haven't tried any alternative, there
were none when I began and I don't really feel like changing horses
now. I suspect it is also the most powerful. 

What people like about other systems is the 'integration'. The gEDA
suite is clearly two disparate major tools, with completely different
file structures, but as both are text based, it's not hard to plumb one
into the other. There are a number of command-line utilities, and
scripts and spreadsheets to generate families of parts.

I find I need to make most of the footprints I use, and a lesser number
of schematic symbols: there are libraries, and many user contributions
around the Net, but there are so many hundreds of thousands of parts
that a lot have to be made from scratch, which isn't difficult.

I'm not sure what kind of connection with LibreCAD there could be: DXF
is a much more complex file structure, and I think the most that could
be done would be to transfer PCB outlines and mounting points. There is
some provision for component height in PCB, but no easy way to
manipulate values, and I don't believe LibreCAD can do anything in the
way of 3D anyway.

-- 
Joe

Re: EDA software.

[deloptes]

pe...@easthope.ca wrote:

> At https://wiki.debian.org/DebianTinker/Desktop#EDA is a list of
> packages for electronics design automation.  According to various
> documents, Electric, Fritzing and gEDA, at least, can help to create
> schematics.  I use librecad but have never used schematic construction
> software.  Which of the EDA packages will be a good starting point?
> Is any integrated with Librecad?

Hi,
I am not an expert, just for hobby used few times the packages. And I don't
know if it is integrated in librecad. chances are good because they use
well known formats, but no idea.
on the other hand it depends on what you want to do. For example I used geda
(gschem) to create a model and ngspice as simulator to test it and then
export the schematics and design the layout in pcb (gsch2pcb). 

For few small projects it worked very good.

I hope it helps

EDA software.

[peter]

Hi,

At https://wiki.debian.org/DebianTinker/Desktop#EDA is a list of 
packages for electronics design automation.  According to various 
documents, Electric, Fritzing and gEDA, at least, can help to create 
schematics.  I use librecad but have never used schematic construction 
software.  Which of the EDA packages will be a good starting point?  
Is any integrated with Librecad?

Thanks,... Peter E.
-- 

123456789 123456789 123456789 123456789 123456789 123456789 123456789
Tel: +1 360 639 0202  Pender Is.: +1 250 629 3757
http://easthope.ca/Peter.html  Bcc: peter at easthope. ca

Re: [OT] Relavant mailing list or USENET group

[Richard Owlett]

On 12/06/2017 05:36 AM, Richard Hector wrote:

On 06/12/17 23:46, Dan Purgert wrote:

Eric S Fraga wrote:

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable



On Tuesday,  5 Dec 2017 at 14:53, Richard Owlett wrote:



[...]



I've seen the term "RSS", but never had any contact with it. Not sure
if SeaMonkey 2.48 can use it.



No idea.  Never used SeaMonkey...


2 seconds of googling indicate you'd likely need a plugin.  But if "use
a plugin" is good enough, then "yes Seamonkey supports RSS feeds"


https://www.seamonkey-project.org/doc/features

"*Feed detection* notifies you when web pages offer RSS or Atom feeds,
and feed preview lets you view their contents and choose a reader with
which to subscribe to those—including an internal reader in the Mail &
Newsgroups component of SeaMonkey."

"*Blogs & News Feeds* is a reader for RSS and Atom feeds right in your
messaging center that eases your reading of information from all across
the web."

Richard



ROFL
I had first used F1  entering RSS in "Search box".
All it had was links to a couple of definitions ;{
HOWEVER, using "feed" as search term yielded a copious plethora of info.
Looks like I have a reading assignment.
*THANK YOU*

Re: [OT] Relavant mailing list or USENET group

[Richard Hector]

On 06/12/17 23:46, Dan Purgert wrote:
> Eric S Fraga wrote:
>> --=-=-=
>> Content-Type: text/plain
>> Content-Transfer-Encoding: quoted-printable
> 
>> On Tuesday,  5 Dec 2017 at 14:53, Richard Owlett wrote:
> 
>> [...]
> 
>>> I've seen the term "RSS", but never had any contact with it. Not sure
>>> if SeaMonkey 2.48 can use it.
> 
>> No idea.  Never used SeaMonkey...
> 
> 2 seconds of googling indicate you'd likely need a plugin.  But if "use
> a plugin" is good enough, then "yes Seamonkey supports RSS feeds"

https://www.seamonkey-project.org/doc/features

"*Feed detection* notifies you when web pages offer RSS or Atom feeds,
and feed preview lets you view their contents and choose a reader with
which to subscribe to those—including an internal reader in the Mail &
Newsgroups component of SeaMonkey."

"*Blogs & News Feeds* is a reader for RSS and Atom feeds right in your
messaging center that eases your reading of information from all across
the web."

Richard



signature.asc
Description: OpenPGP digital signature

Re: [OT] Relavant mailing list or USENET group

[Richard Owlett]

On 12/06/2017 04:46 AM, Dan Purgert wrote:


Eric S Fraga wrote:

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tuesday,  5 Dec 2017 at 14:53, Richard Owlett wrote:

[...]


I've seen the term "RSS", but never had any contact with it. Not sure
if SeaMonkey 2.48 can use it.


No idea.  Never used SeaMonkey...


2 seconds of googling indicate you'd likely need a plugin.  But if "use
a plugin" is good enough, then "yes Seamonkey supports RSS feeds"




In my search I intended to rule out plugins etc. [Intentionally have 
avoided plugins since Netscape days - a personal preference]. I came 
across some posts suggestive that RSS was available at one time.

Re: [OT] Relavant mailing list or USENET group

[Dan Purgert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Eric S Fraga wrote:
> --=-=-=
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
>
> On Tuesday,  5 Dec 2017 at 14:53, Richard Owlett wrote:
>
> [...]
>
>> I've seen the term "RSS", but never had any contact with it. Not sure
>> if SeaMonkey 2.48 can use it.
>
> No idea.  Never used SeaMonkey...

2 seconds of googling indicate you'd likely need a plugin.  But if "use
a plugin" is good enough, then "yes Seamonkey supports RSS feeds"

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJaJ8qOAAoJEI4R3fMSeaKBHwcH/jzg4KOLM+DbRBLDOMbkVKcx
Vmb1t+qsmA8zNPOgNow/Rxpoz+B71IqU9gqhmckHzSV1laUie0g7jxoh2ALUrvyU
k2TrDeFmMSkCsiuNnbgomVi0t+yknkkac5IPI6LiVajbbdm0zxrI7YeQV4CGQwXU
V3P88xuI2STtOIX/U0NOcQ2rOj18XL8uPWwAR3Ssyj3A7UWDYP2Lys+OmzyK45EK
dHI9iLefDQcMUjnp/ExSpXL3QFrARVzh3IGE+QEXVKRsldH4anAD6f4MHsOdl/Qd
qqbHpSQbalbrIQDBs9YVfhx425A456ZNn/xDxbOiLMVgoF6fFiX/1IQDbPR/n8s=
=71o6
-END PGP SIGNATURE-

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily unavailable) after Upgrade

[basti]

Hello,

I have upgrade my debian samba domain controller yesterday.
After that I get on both (dc1 and dc2) this error:

Could not get lock /var/lib/apt/lists/lock - open (11: Resource
temporarily unavailable)

I have try to remove the look and list files, reconfigure all installed
packages but the error is still present. I have also try to reboot.

Any ideas how can I fix this?

Best Regards,
basti

Re: Nvidia driver installing newer releases from SVN

[Floris]

Op Tue, 05 Dec 2017 21:03:46 +0100 schreef Benny Simonsen  
:



Hi,

System: Fresh Debian 9
I have a Nvidia GT 1030, that needs 384 (or newer), and I have followed  
the guide listed here:

https://wiki.debian.org/NvidiaGraphicsDrivers#Building_newer_releases_from_SVN
Last step: svn-buildpackage --svn-ignore -us -uc -rfakeroot

But whats next, have tried cd to buid-area folder, containg the deb  
files, and "dpkg -i *.deb", but leaves unconfigured >packages and other  
issues.


Not all packages are needed and can't be installed at the same time (glvnd  
and non-glvnd). Start with the nvidia-driver meta package and resolve the  
dependencies. Or make a local repo and let apt resolve the dependencies.