@Timo Aaltonen: Please review my post and patch again. The patch changes how SHMConfig works! The problem with SHMConfig "on" was, that it created a shared memory with permission bits set to 0777. I agree with you that this is not acceptable, because any (unpriviligized) local user could have written to the memory area of a root process, and Illegal values may cause undefined behavior. My patch resolves this by assigning the memory to a specific, privileged group, and setting the permission bits to 0770. Default SHMConfig "on" and default SHMGroup "admin" can not cause any trouble this way, because even when the data structure is located in a shared memory area, only the root user and users in the admin group have access to it. And users in the admin group have already root acces (via sudo) by default, so they could become root, and modify the particular memory area either way. Please point it out if I miss something, but I don't see a security issue anymore.
It would be also possible to let SHMConfig as it is (and off by default), and introduce my patch as the SHMSecureConfig option, which could be on by default. Shall I rewrite my patch in this way? Also I would be grateful for any information about the control interface you mentioned earlier. Is this the static int ControlProc(LocalDevicePtr local, xDeviceCtl * control) in synaptics.c? -- SHMConfig should be enabled by default, and gsynaptics should be installed by default on laptops https://bugs.launchpad.net/bugs/155937 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
