Bug#929063: Moving SELinux check
On 5/22/19 11:57 AM, Thorsten Glaser wrote: > On Wed, 22 May 2019, Jesse Smith wrote: > >> I don't think removing the SELinux dependency from init actually saves >> us any RAM. Several other services link to these libraries too, so the > Maybe, maybe not. (I’m fairly sure I’ve got some VMs without.) > > Other services can, however, be more easily restarted than the entire > system, in case of a security fix for that library. > > How do you think an attacker would exploit a flaw in a SELinux library through init? SysV init doesn't interact with the user, doesn't read any files directly after it's up and running, doesn't listen on any sockets. About the only way to interact with PID1 is through a pipe that can only be written to by root.
Bug#929063: Moving SELinux check
On Wed, 22 May 2019, Jesse Smith wrote: > I don't think removing the SELinux dependency from init actually saves > us any RAM. Several other services link to these libraries too, so the Maybe, maybe not. (I’m fairly sure I’ve got some VMs without.) Other services can, however, be more easily restarted than the entire system, in case of a security fix for that library. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#929063: Moving SELinux check
On 5/21/19 8:45 PM, Dmitry Bogatov wrote: > [2019-05-18 16:14] Jesse Smith >> From a practical perspective, I'm curious if there is any benefit or >> drawback. Is this patch fixing a known bug, >> does it significantly reduce the size of PID 1 in memory? > Not that I really care about 1Mb of RAM, but: > > 152K /lib/x86_64-linux-gnu/libselinux.so.1 > 692K /lib/x86_64-linux-gnu/libsepol.so.1 > 460K /lib/x86_64-linux-gnu/libpcre.so.3.13.3 I don't think removing the SELinux dependency from init actually saves us any RAM. Several other services link to these libraries too, so the libraries are loaded into RAM anyway and should be shared between the various services. Unless SELinux is culled from every low-level daemon that 1MB RAM is still going to be used.
Bug#929063: Moving SELinux check
[2019-05-18 16:14] Jesse Smith > From a practical perspective, I'm curious if there is any benefit or > drawback. Is this patch fixing a known bug, > does it significantly reduce the size of PID 1 in memory? Not that I really care about 1Mb of RAM, but: 152K/lib/x86_64-linux-gnu/libselinux.so.1 692K/lib/x86_64-linux-gnu/libsepol.so.1 460K/lib/x86_64-linux-gnu/libpcre.so.3.13.3 -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#929063: Moving SELinux check
I've looked over the patch and the logic seems straight forward enough. Philosophically, I can see arguments for doing this (simplify the core of init, remove a dependency) and against this idea (it adds a new program to the sysvinit package and start-up process). So from a philosophical stand point I'm fairly neutral on this new approach. >From a practical perspective, I'm curious if there is any benefit or drawback. Is this patch fixing a known bug, does it significantly reduce the size of PID 1 in memory? Is there a flaw in libselinux is known to cause problems if init is linked to it? I'd like to hear some options on why we might apply this (or not) upstream. - Jesse
