Bug#845385: Privilege escalation via removal

Emmanuel wrote: >> Might protect against "static" things, but vulnerable to a race. > I'm not sure to understand, what kind of race could happen here? Hmm... You suggested some chmod before chown. Your attacker sits tight, waits for the chmod, then creates the "bad thing" in readiness for your

Bug#845385: Privilege escalation via removal

On 30.11.2016 14:17, Emmanuel Bourg wrote: > Le 22/11/2016 à 23:35, Paul Szabo a écrit : > >> Then if the tomcat8 package is removed (purged?), the postrm script runs >> chown -Rhf root:root /etc/tomcat8/ >> and that will leave the file world-writable, setgid root > > What about switching the

Bug#845385: Privilege escalation via removal

Le 22/11/2016 à 23:35, Paul Szabo a écrit : > Then if the tomcat8 package is removed (purged?), the postrm script runs > chown -Rhf root:root /etc/tomcat8/ > and that will leave the file world-writable, setgid root What about switching the files left to nobody:nogroup instead of root:root?

Bug#845385: Privilege escalation via removal

Hi Paul, Le 23/11/2016 à 01:46, paul.sz...@sydney.edu.au a écrit : > Might protect against "static" things, but vulnerable to a race. I'm not sure to understand, what kind of race could happen here? > But really... why do you care about leaving some "dangling" useless > object, owned by some

Bug#845385: Privilege escalation via removal

Le 30/11/2016 à 00:20, Markus Koschany a écrit : > rm -rf /etc/tomcat8 > > I mean purge means purge. Remove all files, don't leave anything behind. That's tempting but I wonder if we aren't missing something. Other packages are installing things under /etc/tomcat8, for example solr-tomcat and

Bug#845385: Privilege escalation via removal

Le 29/11/2016 à 23:45, Markus Koschany a écrit : > I don't understand why this is a security issue when > /etc/tomcat8/Catalina/attack is owned by root:root after the purge and > the tomcat8 user doesn't even exist anymore. My understanding is that the file is left with execution permissions for

Bug#845385: Privilege escalation via removal

I think the solution is quite simple. Let's replace chown -Rhf root:root /etc/tomcat8/ || true with rm -rf /etc/tomcat8 I mean purge means purge. Remove all files, don't leave anything behind. As another improvement suggestion for Tomcat 9, we could stop deleting the tomcat user on purge and

Bug#845385: Privilege escalation via removal

> I don't understand why this is a security issue when > /etc/tomcat8/Catalina/attack is owned by root:root after the purge and > the tomcat8 user doesn't even exist anymore. Nevermind. I missed the "world". However dpkg warns about that /etc/tomcat8/Catalina is not empty on purge, so the admin

Bug#845385: Privilege escalation via removal

On Wed, 23 Nov 2016 09:35:34 +1100 Paul Szabo wrote: > Package: tomcat8 > Version: 8.0.14-1+deb8u4 > Severity: critical > Tags: security > > Having installed tomcat8, the directory /etc/tomcat8/Catalina is set > writable by group tomcat8, as per the postinst script.

Bug#845385: Privilege escalation via removal

Dear Emmanuel, > Do you think running something like "chmod -R 640 /etc/tomcat8" right > before the chown is an appropriate solution to this issue? Might protect against "static" things, but vulnerable to a race. Your postrm script might want to kill all tomcat8 processes, also. That might be a

Bug#845385: Privilege escalation via removal

Package: tomcat8 Version: 8.0.14-1+deb8u4 Severity: critical Tags: security Having installed tomcat8, the directory /etc/tomcat8/Catalina is set writable by group tomcat8, as per the postinst script. Then the tomcat8 user, in the situation envisaged in DSA-3670 and DSA-3720, see also