[opensuse-kde] Some kde and Qt apps require exec flag in ~/.cache
Hello KDE Community! I found out two applications spectacle and qtcreator have for some time begun to require exec flag in ~/.cache without which it crashing, since it is assumed that the execution of files should be allowed from this directory. Is it correct? Is it secure? How do you think? I'm in my fstab, for perfomance and security reasons, specify this: tmpfs /tmp tmpfs nodev,nosuid,size=2G 0 0 tmpfs /var/tmp tmpfs nodev,nosuid,size=2G 0 0 tmpfs /var/cache/zypp tmpfs nodev,nosuid,noexec,mode=0755,size=2G 0 0 tmpfs /run tmpfs nodev,nosuid,noexec,mode=0755,size=32m 0 0 tmpfs /run/lock tmpfs nodev,nosuid,noexec,mode=0755,size=8m 0 0 tmpfs /root/.cache tmpfs nodev,nosuid,noexec,mode=0700,size=2G 0 0 tmpfs /home/ilya/.cache tmpfs nodev,nosuid,noexec,mode=0700,uid=1000,size=2G 0 0 tmpfs /var/lib/wwwrun/.cache tmpfs nodev,nosuid,noexec,mode=0700,uid=30,size=2G 0 0 And it seems to me that you should not allow "decent" applications to run files from the cache, for reasons of security. In extreme cases, it can explicitly use /bin/sh to run, but do not require the ability to run any executable that can replace any other application with same permissons? And the application should not be crashed because it is not possible to do it. Do you think this is a bug? -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Hi, Am Samstag, 30. September 2017, 02:13:27 CEST schrieb Илья Индиго:
Hello KDE Community!
I found out two applications spectacle and qtcreator have for some time begun to require exec flag in ~/.cache without which it crashing, since it is assumed that the execution of files should be allowed from this directory.
Is it correct? Is it secure? How do you think?
This is likely the QML JIT cache, where V4 saves the generated code to a file.
I'm in my fstab, for perfomance and security reasons, specify this:
tmpfs /tmp tmpfs nodev,nosuid,size=2G 0 0 tmpfs /var/tmp tmpfs nodev,nosuid,size=2G 0 0 tmpfs /var/cache/zypp tmpfs nodev,nosuid,noexec,mode=0755,size=2G 0 0 tmpfs /run tmpfs nodev,nosuid,noexec,mode=0755,size=32m 0 0 tmpfs /run/lock tmpfs nodev,nosuid,noexec,mode=0755,size=8m 0 0 tmpfs /root/.cache tmpfs nodev,nosuid,noexec,mode=0700,size=2G 0 0 tmpfs /home/ilya/.cache tmpfs nodev,nosuid,noexec,mode=0700,uid=1000,size=2G 0 0 tmpfs /var/lib/wwwrun/.cache tmpfs nodev,nosuid,noexec,mode=0700,uid=30,size=2G 0 0
And it seems to me that you should not allow "decent" applications to run files from the cache, for reasons of security. In extreme cases, it can explicitly use /bin/sh to run, but do not require the ability to run any executable that can replace any other application with same permissons? And the application should not be crashed because it is not possible to do it.
Do you think this is a bug?
No, AFAIK the file's contents are verified to match the .qml file (could probably be faked though). Anyway, if an application can write arbitrary files you already have code exec so there's no privesc. Cheers, Fabian -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On 29/09/17 08:13 PM, Илья Индиго wrote:
I'm in my fstab, for perfomance and security reasons, specify this:
tmpfs /tmp tmpfs nodev,nosuid,size=2G 0 0 tmpfs /var/tmp tmpfs nodev,nosuid,size=2G 0 0 tmpfs /var/cache/zypp tmpfs nodev,nosuid,noexec,mode=0755,size=2G 0 0 tmpfs /run tmpfs nodev,nosuid,noexec,mode=0755,size=32m 0 0 tmpfs /run/lock tmpfs nodev,nosuid,noexec,mode=0755,size=8m 0 0 tmpfs /root/.cache tmpfs nodev,nosuid,noexec,mode=0700,size=2G 0 0 tmpfs /home/ilya/.cache tmpfs nodev,nosuid,noexec,mode=0700,uid=1000,size=2G 0 0 tmpfs /var/lib/wwwrun/.cache tmpfs nodev,nosuid,noexec,mode=0700,uid=30,size=2G 0 0
Well, that's interesting, but I don't see why you specify those in your FSTAB. See TMPFILES.D(5) My system (LEAP 42.2, although it was doing all the tmpfs stuff in my old 13.2 system as well) creates /run as a tmpfs and links or b-mounts other things to it. All without entries in FSTAB. I wonder, oh how I wonder, how it does that :-) Perhaps it has something to do with systemd. I must run an 'apropos' to find out :-) -- For the time will come when men will not put up with sound doctrine. Instead, to suit their own desires, they will gather around them a great number of teachers to say what their itchingears want to hear. -- II Timothy 4:3 -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On 2017-09-30 14:36, Anton Aylward wrote:
On 29/09/17 08:13 PM, Илья Индиго wrote:
I'm in my fstab, for perfomance and security reasons, specify this:
tmpfs /tmp tmpfs nodev,nosuid,size=2G 0 0 tmpfs /var/tmp tmpfs nodev,nosuid,size=2G 0 0 tmpfs /var/cache/zypp tmpfs nodev,nosuid,noexec,mode=0755,size=2G 0 0 tmpfs /run tmpfs nodev,nosuid,noexec,mode=0755,size=32m 0 0 tmpfs /run/lock tmpfs nodev,nosuid,noexec,mode=0755,size=8m 0 0 tmpfs /root/.cache tmpfs nodev,nosuid,noexec,mode=0700,size=2G 0 0 tmpfs /home/ilya/.cache tmpfs nodev,nosuid,noexec,mode=0700,uid=1000,size=2G 0 0 tmpfs /var/lib/wwwrun/.cache tmpfs nodev,nosuid,noexec,mode=0700,uid=30,size=2G 0 0
Well, that's interesting, but I don't see why you specify those in your FSTAB.
For _security_ It is not the default settings. He is doing those. He disallows anything from running off those. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 01/10/17 09:06 AM, Carlos E. R. wrote:
On 2017-09-30 14:36, Anton Aylward wrote:
On 29/09/17 08:13 PM, Илья Индиго wrote:
I'm in my fstab, for perfomance and security reasons, specify this:
tmpfs /tmp tmpfs nodev,nosuid,size=2G 0 0 tmpfs /var/tmp tmpfs nodev,nosuid,size=2G 0 0 tmpfs /var/cache/zypp tmpfs nodev,nosuid,noexec,mode=0755,size=2G 0 0 tmpfs /run tmpfs nodev,nosuid,noexec,mode=0755,size=32m 0 0 tmpfs /run/lock tmpfs nodev,nosuid,noexec,mode=0755,size=8m 0 0 tmpfs /root/.cache tmpfs nodev,nosuid,noexec,mode=0700,size=2G 0 0 tmpfs /home/ilya/.cache tmpfs nodev,nosuid,noexec,mode=0700,uid=1000,size=2G 0 0 tmpfs /var/lib/wwwrun/.cache tmpfs nodev,nosuid,noexec,mode=0700,uid=30,size=2G 0 0
Well, that's interesting, but I don't see why you specify those in your FSTAB.
For _security_
It is not the default settings. He is doing those. He disallows anything from running off those.
Yes, I understand that. look, what he's doing is creating lots-a-lots of tmpfs I have no 'tmpfs' line at all AT ALL AT ALL in my FSTAB but I still have .. # mount | grep tmpfs devtmpfs on /dev type devtmpfs (rw,nosuid,size=1943064k,nr_inodes=485766,mode=755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /var/run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /run/user/501 type tmpfs (rw,nosuid,nodev,relatime,size=390008k,mode=700,uid=501,gid=501) tmpfs on /var/run/user/501 type tmpfs (rw,nosuid,nodev,relatime,size=390008k,mode=700,uid=501,gid=501) What this doesn't make clear is that mount of those are "mount -b" or symlinks. I've inserted a blank like to make it clear what there are two groupings there. See, for example, /usr/lib/systemd/system/var-lock.mount See, also, /usr/lib/tmpfiles.d/* Now I could override that, and add appropriate lines under a custom tmpfile conf to bind-mount or symlink all of those nice extras that Илья Индиго mentions, all without the need to create more and more individual shared memory segments. After all, that's the way its already being done. See also /etc/systemd/logind.conf and logind.conf(5) for to size of the per user (/run/user/501, size=390008k in my case) space I'd also not that he has BOTH /tmp and /var/tmp as tmpfs. That means that will BOTH go away at reboot and be recreated. I think this is nasty. Various sources (go google for yourself, there are many), even those that admit to /tmp as a tmpfs, make the use difference between them clear, in both size of files (aka run your ISOs thou /var/tmp) and lifetime (expect your ISO in /var/tmp to be there after reboot but don't expect anything /tmp to be there after reboot). I think that is reasonable. I think the cleaning strategy using the tools we have are perfectly reasonable. As far as the security of /var and /var/tmp goes, well, that's not a problem for me: I use LVM to create yet another LE for that. You could always use a remount: Tie yourself in knots with mount -o rw --bind /var/tmp /var/tmp I'd further note that in late model Linux there is no reason why /tmp should still be a shared namespace. -- There is no legitimate religion apart from truth. --John Calvin -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On 2017-10-01 18:44, Anton Aylward wrote:
On 01/10/17 09:06 AM, Carlos E. R. wrote:
On 2017-09-30 14:36, Anton Aylward wrote:
On 29/09/17 08:13 PM, Илья Индиго wrote:
I'm in my fstab, for perfomance and security reasons, specify this:
tmpfs /tmp tmpfs nodev,nosuid,size=2G 0 0 tmpfs /var/tmp tmpfs nodev,nosuid,size=2G 0 0 tmpfs /var/cache/zypp tmpfs nodev,nosuid,noexec,mode=0755,size=2G 0 0 tmpfs /run tmpfs nodev,nosuid,noexec,mode=0755,size=32m 0 0 tmpfs /run/lock tmpfs nodev,nosuid,noexec,mode=0755,size=8m 0 0 tmpfs /root/.cache tmpfs nodev,nosuid,noexec,mode=0700,size=2G 0 0 tmpfs /home/ilya/.cache tmpfs nodev,nosuid,noexec,mode=0700,uid=1000,size=2G 0 0 tmpfs /var/lib/wwwrun/.cache tmpfs nodev,nosuid,noexec,mode=0700,uid=30,size=2G 0 0
Well, that's interesting, but I don't see why you specify those in your FSTAB.
For _security_
It is not the default settings. He is doing those. He disallows anything from running off those.
Yes, I understand that.
look, what he's doing is creating lots-a-lots of tmpfs
Irrelevant. That's not the problem or question, but why some program try to create executables there, and why does it crash when it gets denied. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 02/10/17 08:13 AM, Carlos E. R. wrote:
Irrelevant. That's not the problem or question, but why some program try to create executables there, and why does it crash when it gets denied.
I agree that caches should be noexec, but I think this is a heavy handed way of working and has nothing to do with solving the problem of that WHAT and the WHY. Yes, it is reminiscent of early Microsoft. But I'm not a coder and I'm not a forensic specialist, but I'd still approach this by running the program under the debugger to see where it crashed. At least it would tell me where it crashed, if it was in the code body or a library, and what it was trying to access or set up when that happened. The I would have something specific to bring to the attention of the list and the developer, a SPECIFIC bug to report. I agree with you when you say in an earlier post that it is about security. If we didn't have other tools I'd be investigating doing a lot of binding of directories to make them read only and/or no-exec. But the /dev/shm or as tis example does it, tmpfs also makes clear that those directories are flushed. I can understand flushing /tmp. I don't think flushing some caches is a good idea. For example under /var/cache/zypp/solv there are keys and sat-solver files. If you flush those, you need to rebuild them all from scratch when you 'zypper [d]up' or the YaST equivalent. Big OUCH. You want a nodev,nosuid,noexec there? Good. Fine. Do it with a Bind. The point I'm making here, having to make as you've done the switcheroo between your last two posts between solely saying "security" and solely saying it's an execution bug, is that all this is using a blunderbuss to address a mosquito. Yes, the mosquito is pernicious, but the blunderbuss is causing collateral damage that is not necessary. -- have both /tmp and /var/tmp as tmps is too heavy handed, there is no persistent scratch namespace -- purging caches is counter-productive it defeats the purpose of caches and impacts performance when they need to be rebuilt -- having /run as a tmpfs, whcih is the norm, means that everything under it such as /run/lock, is already in the tmpfs, so no need to duplicate that -- having established /run as a a tmpfs many things can be done simply by linking to is. You can see examples of this in /usr/lib/udev/rules.d -- most of these items would be better done as links, symlinks or as mount-binds. It would put less demand on the shared memory system and swap, be better handled by the kernel (I'll detail that if you want) -- why aren't you using apparmor? -- why aren't you suing the regular file access controls? A principle of debugging is 'wolf fencing'. That is, setting up a boundary (fence) and determining which side of it the bug (wolf) is on it. Right now there s a lot going on here. We can't know if problem is is a result of the noexec restriction or, perhaps, it being a problem with the application trying to create a socket (rather than a device) on a nodev? Yes, I agree, there are proper places to create public and private sockets, and cache directories should, perhaps, not be those. However I can think of arguments where they should be, but that's another matter. I know I can create a pipe on a nodev mounted /tmp, but a socket? -- "Unsustainable" is the new go-to term for "don't do something we don't like and don't ask for an actual reason." -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
participants (4)
-
Anton Aylward -
Carlos E. R. -
Fabian Vogt -
Илья Индиго