Re: GnuPG and SSH_AUTH_SOCK value
Daniel Kahn Gillmor via Gnupg-users wrote in <87ftnup18e.fsf@fifthhorsem\ an.net>: |On Fri 2019-06-28 10:04:44 +0200, Michael Kesper wrote: |> On 23.06.19 12:21, Matthias Apitz wrote: |>> I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE: |> |> This makes your setup depend on a suid binary. | |Can you give more details? I know that some older systems did rely on X |or startx or something being setuid, but i think more modern systems |don't require that. On a debian testing (buster) system, for example, i |don't believe that any of the binaries are suid. ..because some packagers do CRUX to avoid it, maybe because they do not want to violate some policy. For example, for the MUA i maintain, Debian ships with the privilege-separated "dotlock" helper, but does not install it SETUID. This is good enough for the shared mail directory the way Debian does it, in fact the package maintainer is pretty clever, right, but of course this is not how it is designed; today: it was a SETGID helper in the past, but that does not work on eg. OpenBSD where only root can write in the mail spool. And since this MUA supports multiple mail spools, it will not work unless they are setup in exactly the same way. But only normal file-locking, as is the chosen approach on OpenBSD (for my MUA), is not the way the Debian maintainer wants to go. Well, this is his choice. (Besides i am in total favour of not having SETUID, not only because i had a CVE myself. Here Xorg still is SETUID, but i have never looked too deep. For graphics hardware access, you need to have access to hardware, no. Ie., whether hardware is designed so that this becomes possible, i do not know. Being able to start a program SETUID, open some files, and then enter a restricted mode which has lost root rights, i do not feel bad about. Like the FreeBSD capsicum thing, or even CloudABI. Maybe i even prefer being able to search SETUID and have a list, instead of having very complicated configuration settings, and CRUX, hidden here and there. But i am not a security researcher, i just try to do a little thing right.) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG and SSH_AUTH_SOCK value
On Fri 2019-06-28 11:09:36 +0200, Michael Kesper wrote: > On 28.06.19 10:23, Daniel Kahn Gillmor wrote: >> On Fri 2019-06-28 10:04:44 +0200, Michael Kesper wrote: >>> On 23.06.19 12:21, Matthias Apitz wrote: I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE: >>> >>> This makes your setup depend on a suid binary. >> >> Can you give more details? I know that some older systems did rely on X >> or startx or something being setuid, but i think more modern systems >> don't require that. On a debian testing (buster) system, for example, i >> don't believe that any of the binaries are suid. > > The setuid binary is called xserver-xorg-legacy and can be installed in > buster (new installs don't get it afaik, but I'm not sure about upgrading): > https://packages.debian.org/de/buster/xserver-xorg-legacy > Matthias explicitly mentioned he used startx so I think this is > relevant. I also use startx on buster systems, but i don't have xserver-xorg-legacy installed, so i think this is not the strict dependency it sounded like originally. I know that i used to depend on a setuid X server, so i'm gratefuly to the folks who did the work to remove that setuid requirement! Anyway, i think we're pretty far off-topic here, so i'll drop off this thread, just wanted to confirm that i hadn't missed something. all the best, --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: New keyserver at keys.openpgp.org - what's your take?
Hi all, On 27.06.19 03:18, Vincent Breitmoser via Gnupg-users wrote: > The definition of personal data, Article 4: > >> (1) ‘personal data’ means any information relating to an identified or >> identifiable natural person (‘data subject’); an identifiable natural person >> is one who can be identified, directly or indirectly, in particular by >> reference to an identifier such as a name, (...), or an online identifier >> (...); > > Given that there is legal commentary that even IP addresses in logs already > count as personal data, I don't find it contestable that e-mail addresses do > constitute personal data. Definitely. If you can identify someone by data, it IS personal data. As many email addresses are firstname.lastname@ they are already directly identifiable. See also: https://www.gdpreu.org/the-regulation/key-concepts/personal-data/ Best Michael signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG and SSH_AUTH_SOCK value
Hi Daniel, On 28.06.19 10:23, Daniel Kahn Gillmor wrote: > On Fri 2019-06-28 10:04:44 +0200, Michael Kesper wrote: >> On 23.06.19 12:21, Matthias Apitz wrote: >>> I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE: >> >> This makes your setup depend on a suid binary. > > Can you give more details? I know that some older systems did rely on X > or startx or something being setuid, but i think more modern systems > don't require that. On a debian testing (buster) system, for example, i > don't believe that any of the binaries are suid. The setuid binary is called xserver-xorg-legacy and can be installed in buster (new installs don't get it afaik, but I'm not sure about upgrading): https://packages.debian.org/de/buster/xserver-xorg-legacy Matthias explicitly mentioned he used startx so I think this is relevant. Bye Michael signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG and SSH_AUTH_SOCK value
On Fri 2019-06-28 10:04:44 +0200, Michael Kesper wrote: > On 23.06.19 12:21, Matthias Apitz wrote: >> I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE: > > This makes your setup depend on a suid binary. Can you give more details? I know that some older systems did rely on X or startx or something being setuid, but i think more modern systems don't require that. On a debian testing (buster) system, for example, i don't believe that any of the binaries are suid. --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG and SSH_AUTH_SOCK value
Hi Matthias, On 23.06.19 12:21, Matthias Apitz wrote: > I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE: This makes your setup depend on a suid binary. There have been some security issues about that, so maybe it's wise to revise that decision? For example: https://www.exploit-db.com/exploits/45908 Bye Michael signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg-agent systemd user service [was: Re: GnuPG and SSH_AUTH_SOCK value]
Am Mittwoch, den 26.06.2019, 07:47 +0200 schrieb Matthias Apitz: > El día martes, junio 25, 2019 a las 11:12:43a. m. -0400, Daniel Kahn > Gillmor escribió: > > On Tue 2019-06-25 13:07:03 +0200, Dirk Gottschalk via Gnupg-users > > wrote: > > > This is my $HOME/.config/systemd/user/gpg-agent.service: > > If you're using gpg-agent as a systemd user service, please use the > > systemd unit files (.service and .socket definitions) that ship > > with > > GnuPG itself. > > > > ... > Thanks for all the helping hands and hints about systemd(8), but > FreeBSD > normally does not run/use this. AFAIK, there is not even an official > port of it in the FreeBSD's ports collection. I'm sorry, I overread that you are asking about FreeBSD. I had just Linux in mind. Did't want to steal your time. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac signature.asc Description: This is a digitally signed message part ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: New keyserver at keys.openpgp.org - what's your take?
Hello Vicent. I read your explainations and will shorten them up to the points I want to reply to. Am Donnerstag, den 27.06.2019, 03:18 +0200 schrieb Vincent Breitmoser via Gnupg-users: > > (2) ‘processing’ means any operation or set of operations which is > > performed > > on personal data or on sets of personal data, whether or not by > > automated > > means, such as collection, recording, organisation, structuring, > > storage, > > adaptation or alteration, retrieval, consultation, use, disclosure > > by > > transmission, dissemination or otherwise making available, > > alignment or > > combination, restriction, erasure or destruction; > This is most certainly what we are doing. > So assuming that e-mail addresses are personal data, and we process > this data, there is an (exhaustive!) list of possible situations in > which we are lawfully allowed to do so, two of which can potentially > apply. Article 6: > > 1. Processing shall be lawful only if and to the extent that at > > least one of the following applies: > > (a) the data subject has given consent to the processing of his or > > her > >personal data for one or more specific purposes; > > (...) > > (e) processing is necessary for the performance of a task carried > > out in the public interest (...); > The first is clear - if we have consent, we're good. The second > *could* possibly be argued, but I have a hard time believing the > haphazard handling of e-mail addresses on traditional keyservers > serves the public interest. Even if we did assume this, there is the As one of the lawyers I work for told me, the consent could be implicated by the users upload, therefor there must be the mechanism that users can only upload their own keys, so consent is guaranteed. > "right to object", which allows data subjects to object to the use of > their data. Article 21: > > 1. The data subject shall have the right to object, (...) to > > processing of personal data concerning him or her which is based on > > point (e) or (f) of Article 6(1), (...). The controller shall no > > longer process the personal data unless the controller demonstrates > > compelling legitimate grounds for the processing which override the > > interests, rights and freedoms of the data subject (...). > All in all, I find it pretty clear that GDPR does apply to processing > of e-mail addresses on public keyservers. There are various nuanced > conclusions one may draw, for example "it applies, but you probably > won't get sued, so just keep on running them pool servers". It is > unclear to me how one could look at this and conclude that keyservers > aren't affected by GDPR. The User knows how and why the data is processed, if he uploads his key to the server. A deletion has to be possible by the regulation, SKS lacks this mechanism. I haven't tested the new server yet, but I'm planning to do this in the next day. As far as I read, deletion is possible there. > > and the, say, German implementation > GDPR is a [regulation], not a [directive]. As such, it is an > immediately enforcable law that does not require a per-country > implementation to be effective. Yes and no. The EU construct is a little bit strange in this manner, but GDPR was transferred into german law by the renewal of the BDSG last year. > > along with relevant commentary to show why this is a legal > > requirement. > I'm aware of work on this by folks with legal background, but due to > funny academic publishing culture I'm not at liberty to > share. Hopefully something will be available to the public soon. Oh yes, academic publishing culture is indeed a little strange. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac signature.asc Description: This is a digitally signed message part ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
