Re: [systemd-devel] systemd-ask-password and kernel keyring

2018-11-14 Thread Ryan Gonzalez
What would a patch look like? A --user that instead saves it to the user's
active secret service?

--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/

On Wed, Nov 14, 2018, 9:44 AM Lennart Poettering  On Mi, 14.11.18 11:38, Sietse van Zanen (sie...@wizdom.nu) wrote:
>
> > According to man:
> >
> >--keyname=
> >Configure a kernel keyring key name to use as cache for the
> password. If set, then the tool will try to push any collected passwords
> into the
> >kernel keyring of the root user
> >
> >
> > Why only for user root and not the user running
> > systemd-ask-password?
>
> The whole "systemd-ask-password" concept was created with HDD
> passwords in mind, i.e. system stuff. We could of course extend the
> logic to also support unprivileged user stuff, and this has been
> requested before, but so far nobody sent a patch updating things for
> this purpose.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-ask-password and kernel keyring

2018-11-14 Thread Lennart Poettering
On Mi, 14.11.18 11:38, Sietse van Zanen (sie...@wizdom.nu) wrote:

> According to man:
> 
>--keyname=
>Configure a kernel keyring key name to use as cache for the 
> password. If set, then the tool will try to push any collected passwords into 
> the
>kernel keyring of the root user
> 
> 
> Why only for user root and not the user running
> systemd-ask-password?

The whole "systemd-ask-password" concept was created with HDD
passwords in mind, i.e. system stuff. We could of course extend the
logic to also support unprivileged user stuff, and this has been
requested before, but so far nobody sent a patch updating things for
this purpose.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Environment-variable security?

2018-11-14 Thread David Parsley
On Wed, Nov 14, 2018 at 3:43 AM Lennart Poettering 
wrote:

> I mean, seriously, people do lots of stuff. It doesn't mean that all
> what people do is actually a good idea or just safe.
>

Certainly agreed on this point. It is my belief, however, that system
software, where possible, should implement controls to head-off security
mistakes of this kind made by those people - like me. Right now I think
systemd doesn't go far enough - I was lucky that I saw that warning in the
logs, and the contents of my unit file were insecure when I thought it was
secured by file permissions. I still believe systemd should refuse to start
the service to draw attention to this error in thinking, and that the log
entry should probably reference the doc where the not-uncommon practice of
putting secrets in environment variables is discouraged - certainly with
systemd managed services.

The practice will continue, however; TravisCI, CircleCI, and my own
GopherCI all have mechanisms for providing e.g a GITHUB_PASSWORD
environment variable for automated build publishing. No shock that a DevOps
engineer might make the mistake of applying the same principle with systemd.

Regards,
-David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-devel Digest, Vol 103, Issue 11

2018-11-14 Thread Piotr Dobrogost
> Date: Thu, 8 Nov 2018 14:15:18 +0100
> From: Piotr Dobrogost
> Message-ID: <
caa6tfmuar3vnz3bap6fpdjbftutk3gdfkmch_cr7d+by1yj...@mail.gmail.com>

> I enabled unified hierarchy by passing "systemd.unified_cgroup_hierarchy"
> kernel parameter and stat reports "cgroups2fs" yet the limit still doesn't
> work – `cat /proc/$(pidof krusader)/status | grep VmRSS` reports "VmRSS:
> 225452 kB"

How could I try to debug this?

Piotr
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] systemd-ask-password and kernel keyring

2018-11-14 Thread Sietse van Zanen
According to man:

   --keyname=
   Configure a kernel keyring key name to use as cache for the 
password. If set, then the tool will try to push any collected passwords into 
the
   kernel keyring of the root user


Why only  for user root and not the user running systemd-ask-password?

I am working on a project where a user will run a keyserver. currently I do the 
keyctl add etc manually, but it would be much nicer is system-ask-password 
could use the user's keyring.


-Sietse


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to debug occasional hashmap corruption?

2018-11-14 Thread juice

juice kirjoitti 2018-11-06 14:30:

Lennart Poettering kirjoitti 2018-11-06 12:27:

On Di, 06.11.18 11:57, juice (ju...@swagman.org) wrote:



Hi,

During the past half year I have seen systemd dump core three times 
due

to what I suspect a hashmap corruption or race.
Each time it looks a bit different and is triggered by different 
things

but it somehow centers on hashmap operations.

What would be the prefered way to debug this? I cannot add huge 
logging

as this is something that happens once in a blue moon and always in
different compute nodes.
Is there some way I could easily test it by increasing the chance of 
such

corruption/race happening?


This looks very much like a memory corruption of some sorts and
valgrind should be the tool of choice to track that down.

Lennart


Thanks tor the prompt reply, Lennart.

I agree; using valgrind indeed was something already considered, 
however I

suspect it might add some overhead in systemd operation?


I have been trying to start systemd under valgrind but seems it is not a 
trivial
task to do. Moreover, no searching has revealed a general receipe for 
doing that
other than the advice in systemd README's to compile with 
-Dvalgrind=true option.


So, where could I find information on how to set up memory corruption 
debug on

a live system for testing?

 - juice -

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Environment-variable security?

2018-11-14 Thread Lennart Poettering
On Mi, 14.11.18 02:17, Marek Howard (marek...@gmail.com) wrote:

> > It is not *that* common to pass secrets via environment variable but
> > it's nothing unusual, and many programs offer this interface. OpenVPN
> > comes to bind. Where such interface is offered, propagating down the
> > process tree is usually not a concern, because such programs usually
> > don't fork "untrusted" programs.

Well, what's "trusted" or "untrusted" is in the eye of the beholder,
and you never know what your libraries do in the background.

What is common or not is orthogonal to what is a good idea and what is
not.

> If you want some examples:
> 
> borgbackup - BORG_PASSPHRASE
> restic - RESTIC_PASSWORD
> openssl - env:var
> rsync - RSYNC_PASSWORD
> hub - GITHUB_PASSWORD, GITHUB_TOKEN
> rclone - RCLONE_CONFIG_PASS
> smbclient - PASSWD

Well, if you look at those, at least some of them even take the
password from the command line (for example: smbclient). And as
hopefully everyone knows any information included in the command line
is readily visible to everybody else (including unprivileged) on the
system with "ps". And yes, tools doing that tend to override them
quickly after reading, but that's still awfully racy.

I mean, seriously, people do lots of stuff. It doesn't mean that all
what people do is actually a good idea or just safe.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel