Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-26 Thread Michael Orlitzky
On 11/26/20 5:57 PM, Thomas Deutschmann wrote:
> 
> I disagree here: Packages installing tmpfiles configs requiring
> recursive chown on each boot are doing something wrong from  my P.O.V.

No argument there, but me thinking they're wrong doesn't stop people
from doing it.


> Note that hardlinks aren't even fixed for systemd's tmpfiles provider.
> It will always rely on fs.protected_hardlinks for example. And checking
> for hardlinks like happened to address CVE-2017-18078 will create
> another TOCTOU race. Where is the follow-up report for this?

Systemd only supports Linux, and sets fs.protected_hardlinks=1 itself.
There's not much more we can ask from them.

I normally err on the side of caution, but if someone goes out of their
way to disable a security setting, I don't consider it CVE-worthy if the
thing that setting was preventing is now exploitable.


> In short: As long as it is possible for attacker to write to directory
> you are working on you can never do mentioned things in a safe way. You
> first have to revoke access for everyone except you and then you can
> start checking file per file... but *no* implementation is doing
> something like that.

This came up in the old (late 1990s, early 2000s) LKML discussions about
the protected_* sysctls. The Right Thing To Do is to drop privileges to
the user who owns the directory if you need to do stuff in a directory
that a user owns or can write to.

To quote your earlier message:

> Rule of thumb: Just make sure that you only create top level directories.

...and then drop privileges.





Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-26 Thread David Seifert
On Thu, 2020-11-26 at 17:45 -0500, Michael Orlitzky wrote:
> On 11/26/20 5:37 PM, Peter Stuge wrote:
> > Georgy Yakovlev wrote:
> > > I'll be switching default tmpfiles provider to sys-apps/systemd-
> > > tmpfiles
> > > by the end of the week by updating virtual/tmpfiles ebuild.
> > 
> > Michael Orlitzky wrote:
> > > Corollary: the tmpfiles.d specification can only be implemented
> > > (safely)
> > > on Linux after all.
> > 
> > So should virtual/tmpfiles differentiate based on system?
> > 
> 
> There's no scenario where opentmpfiles is preferable.
> 
> systemd-tmpfiles with the fs.protected_hardlinks=1 sysctl is secure on
> Linux. On other kernels, you're out of luck -- none of the options are
> secure. Securing the service manager on other kernels would require
> dropping tmpfiles entirely, and major changes to OpenRC.
> 

...which is mostly a theoretical exercise, because we only support Linux
anyways.




Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-26 Thread Thomas Deutschmann

On 2020-11-26 21:36, Michael Orlitzky wrote:

Most of these security issues were fixed in systemd-tmpfiles years ago,
and you can easily find upstream tmpfiles.d entries that contain e.g.
"Z" entries. In that case, the upstream file is not in error, and root
doesn't have to be actively tricked into installing anything -- it will
just happen.


I disagree here: Packages installing tmpfiles configs requiring 
recursive chown on each boot are doing something wrong from  my P.O.V. 
like you can never safely do that (you can only take precaution like not 
following symlinks but in this case you don't do what you were asked to 
do so you shouldn't return 'Yup, I chowned everything like you asked me 
to do').




Opentmpfiles literally cannot fix this. There is no POSIX API to safely
handle hardlinks. At best it can be reduced to the same race condition
we have in checkpath, but the entire project would have to be rewritten
in C to accomplish even that.


Note that hardlinks aren't even fixed for systemd's tmpfiles provider. 
It will always rely on fs.protected_hardlinks for example. And checking 
for hardlinks like happened to address CVE-2017-18078 will create 
another TOCTOU race. Where is the follow-up report for this?


In short: As long as it is possible for attacker to write to directory 
you are working on you can never do mentioned things in a safe way. You 
first have to revoke access for everyone except you and then you can 
start checking file per file... but *no* implementation is doing 
something like that.


And keep in mind: We are talking about an attack vector where we already 
assume someone successfully compromised an application and can now do 
everything the application user can do for which we do the work in 
tmpfiles config. Saying that systemd's implementation is more secure 
than OpenTmpfiles' implementation when you are still able to escalate 
privileges is very misleading.



--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-26 Thread Michael Orlitzky
On 11/26/20 5:37 PM, Peter Stuge wrote:
> Georgy Yakovlev wrote:
>> I'll be switching default tmpfiles provider to sys-apps/systemd-tmpfiles
>> by the end of the week by updating virtual/tmpfiles ebuild.
> 
> Michael Orlitzky wrote:
>> Corollary: the tmpfiles.d specification can only be implemented (safely)
>> on Linux after all.
> 
> So should virtual/tmpfiles differentiate based on system?
> 

There's no scenario where opentmpfiles is preferable.

systemd-tmpfiles with the fs.protected_hardlinks=1 sysctl is secure on
Linux. On other kernels, you're out of luck -- none of the options are
secure. Securing the service manager on other kernels would require
dropping tmpfiles entirely, and major changes to OpenRC.



Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-26 Thread Sam James

> On 26 Nov 2020, at 22:37, Peter Stuge  wrote:
> Michael Orlitzky wrote:
>> Corollary: the tmpfiles.d specification can only be implemented (safely)
>> on Linux after all.
> 
> So should virtual/tmpfiles differentiate based on system?
> 

It won’t be keyworded where it’s not available so Portage will skip over it. 
systemd only supports certain platforms.

> 
> //Peter
> 



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-26 Thread Peter Stuge
Georgy Yakovlev wrote:
> I'll be switching default tmpfiles provider to sys-apps/systemd-tmpfiles
> by the end of the week by updating virtual/tmpfiles ebuild.

Michael Orlitzky wrote:
> Corollary: the tmpfiles.d specification can only be implemented (safely)
> on Linux after all.

So should virtual/tmpfiles differentiate based on system?


//Peter



Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-26 Thread Michael Orlitzky
On 11/26/20 10:07 AM, Thomas Deutschmann wrote:
> 
> Only root is allowed to write to these directories. In other words: To
> exploit this, a malicious local user (or a remote attacker who already
> gained user access) would have to trick root into creating specially
> crafted tmpfiles config allowing for race conditions first (according to
> the 10 immutable laws of security, if this is already possible, you are
> already lost).

Most of these security issues were fixed in systemd-tmpfiles years ago,
and you can easily find upstream tmpfiles.d entries that contain e.g.
"Z" entries. In that case, the upstream file is not in error, and root
doesn't have to be actively tricked into installing anything -- it will
just happen.

Opentmpfiles literally cannot fix this. There is no POSIX API to safely
handle hardlinks. At best it can be reduced to the same race condition
we have in checkpath, but the entire project would have to be rewritten
in C to accomplish even that.

Corollary: the tmpfiles.d specification can only be implemented (safely)
on Linux after all.



[gentoo-dev] Dissolving project desktop-misc

2020-11-26 Thread Jonas Stein

Dear all,

sorting packages in a group of "misc" packages was not useful.
We have to dissolve the project desktop-misc

There are some tickets which should be closed first before we reassign 
the packages to maintainer-needed.


It would be good to review if there are packages which have to be tree 
cleaned instead of reassigned. The bug tracker lets assume that some 
packages do not build any more.


On
https://wiki.gentoo.org/wiki/Project:Desktop_Miscellaneous
you will find a ink to all desktop-misc bugs and more useful information 
about dissolving desktop-misc.


Please grab the nice packages.
The first 10 packages are free of charge. ;-)

--
Best,
Jonas



Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-26 Thread Thomas Deutschmann

Hi,

I don't have any objections regarding the change of the default tmpfiles 
provider but I would like to classify the vulnerability:


On 2020-11-25 22:57, Georgy Yakovlev wrote:

In case you don't know, opentmpfiles has an open CVE CVE-2017-18925:
root privilege escalation by symlink attack 
https://github.com/OpenRC/opentmpfiles/issues/4 It has been an issue

for quite a while, reported 3 years ago, and not much changed since.


Don't get scared by 'root privilege escalation': *Any* problem in *any* 
tmpfiles provider will *always* allow for root privilege escalation 
because this service is run by root early at boot.


In theory you could create a user for this service but you would need 
CAP_DAC_OVERRIDE privileges which would again allow for root privilege 
escalation.


Regarding CVE-2017-18925 itself: First you have to understand that 
anyone can request a CVE and that it isn't CNA's job to verify your 
report. That's it, having a CVE doesn't mean that a problem was 
confirmed. A CVE is just an identifier which should allow anyone who 
want to talk about the same problem to do that. For example when we file 
bug 123 in bugs.gentoo.org and Fedora would have the same package and 
experience the same issue they would file bug 456 in their bug tracker 
-- the goal of a CVE is just to connect information regarding the same 
issue -- in this example, the CVE would get references to Gentoo's bug 
123 and Fedora's bug 456.


The bug itself is about a race condition. This race condition is real.

However, the impact is questionable: tmpfiles service will only process 
files from


  /etc/tmpfiles.d/*.conf
  /run/tmpfiles.d/*.conf
  /usr/lib/tmpfiles.d/*.conf

Only root is allowed to write to these directories. In other words: To 
exploit this, a malicious local user (or a remote attacker who already 
gained user access) would have to trick root into creating specially 
crafted tmpfiles config allowing for race conditions first (according to 
the 10 immutable laws of security, if this is already possible, you are 
already lost).


If root doesn't install any tmpfiles config which will create such a 
race condition and if package maintainer will take care that their 
packages won't do the same, you are fine.


Rule of thumb: Just make sure that you only create top level 
directories. If something already exists, error out. Because whenever 
you try to work in a directory where any other user is able to write to 
at the same time, you are always vulnerable to such a race condition 
(that's why you should have a second level for actual user data and keep 
first level for ACL handling -- the service user must only be allowed to 
pass through this directory).



PS: Just to avoid any misunderstandings: OpenTmpfiles should of course 
try to fix/avoid this problem if possible. Security is a layered process 
(like an onion) and having multiple safe-guards is always a good thing.



--
Regards,
Thomas Deutschmann / Gentoo Security Team
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs: x11-misc/zim

2020-11-26 Thread Azamat Hackimov
Hi.
Also created https://github.com/gentoo/gentoo/pull/18411 for taking
maintainership.

чт, 26 нояб. 2020 г. в 12:01, Bernard Cafarelli :
>
> Le Thu, 26 Nov 2020 00:27:53 +0100
> Jonas Stein  a écrit:
>
> > Dear all
> >
> > the following packages are up for grabs while dissolving
> > the desktop-misc project:
> >
> > x11-misc/zim
> > https://packages.gentoo.org/packages/x11-misc/zim
> >
> > It is a very powerful deskop wiki which is written in python. It has
> > many users and it would be great if you would take care for it.
> >
> > It has one open bug with a fix in the comments.
> > https://bugs.gentoo.org/678436
>
> I will take care of it
>
> --
> Bernard Cafarelli (Voyageur)
> Gentoo developer
>


-- 
>From Siberia with Love!



Re: [gentoo-dev] Packages up for grabs: x11-misc/zim

2020-11-26 Thread Bernard Cafarelli
Le Thu, 26 Nov 2020 00:27:53 +0100
Jonas Stein  a écrit:

> Dear all
> 
> the following packages are up for grabs while dissolving
> the desktop-misc project:
> 
> x11-misc/zim
> https://packages.gentoo.org/packages/x11-misc/zim
> 
> It is a very powerful deskop wiki which is written in python. It has 
> many users and it would be great if you would take care for it.
> 
> It has one open bug with a fix in the comments.
> https://bugs.gentoo.org/678436

I will take care of it

-- 
Bernard Cafarelli (Voyageur)
Gentoo developer