Some kde and Qt apps require exec flag in ~/.cache

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Some kde and Qt apps require exec flag in ~/.cache

Fabian Vogt-2
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Some kde and Qt apps require exec flag in ~/.cache

Anton Aylward-2
In reply to this post by Илья Индиго
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Some kde and Qt apps require exec flag in ~/.cache

Carlos E. R.-2
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)


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some kde and Qt apps require exec flag in ~/.cache

Anton Aylward-2
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Some kde and Qt apps require exec flag in ~/.cache

Carlos E. R.-2
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)


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some kde and Qt apps require exec flag in ~/.cache

Anton Aylward-2
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: [hidden email]
To contact the owner, e-mail: [hidden email]