[apparmor] Note: NVIDIA drivers are mapping user-writable files by default

Thu Feb 8 21:25:04 UTC 2018

On Thu, 2018-02-08 at 19:46 +0200, Vincas Dargis wrote:
> On 2/6/18 9:25 PM, Jamie Strandboge wrote:
> > > Anyway, do we _really_ want to allow mmap on writable files..?
> > 
> > Not usually, but in the case of actual shared memory files, there
> > isn't
> > another choice atm. Some day we'll mediate shared memory with non-
> > file
> > rules[1].
> 
> There is a choice to deny it.

Of course. My point was that an nvidia user of the profiled application
is going to expect 3d acceleration from the drivers so a profile that
is meant to work with nvidia should do that (but see below where I
respond to your upstream docs). An admin or profile author can choose
to use nvidia-strict, nvidia, neither, etc.

>  Since these... paths (not originally 
> intended to be a "physical file", except to these .gl*) are requested
> to 
> be mmap'ed for execution, some _real_ file named @{HOME}/#3141528 or 
> /tmp/.glMy1337Exploit could be loaded to enhance attack further. Or
> mine 
> Monero or smth. Or scan Thunderbird's memory for passwords.

Obviously it weakens the profile.

Importantly, if these are actually anonymous shared memory files (the
ones starting with '#'), the kernel shouldn't be creating a name for
the anonymous shared memory that already exists as an actual file.
Furthermore, there needs to be coordination between the processes (ie,
parent/child) to access the kernel file-- an unrelated outside process
can't just start reading from a random anonymous shared memory file.

For the named shared memory files, yes this is potentially an issue,
but an exploitable issue would be a bug in the attacked application.
Applications using shared memory will use an unpredictable path to open
with O_CREAT|O_EXCL, then unlink the file, then pass the fd to the
processes it cares about coordinating with (look in /dev/shm now-- you
won't see anything, as opposed to `sudo lsof|grep '/shm/'` which should
show a lot if you have a browser open).

The paths chosen by the nvidia driver are not ideal, but in practice,
barring bugs, it is mainly that there isn't perfect isolation between
applications (ie, app A and app B can coordinate to share with the
globbed file rules). The other thing it allows is that if an attacker
took control of the profiled application, it could then write out files
that could be mmap'd PROT_EXEC by the application. This is a valid
point, but if you have that much control of the application you don't
need to write out those files.

My point is that the abstractions are meant to be generally usable and
erring on the side of security in an abstraction that is clearly meant
to work with something such that it breaks that something, isn't useful
to anyone. I also mentioned that these would need to be investigated,
which you've done below, which I responded to.

> I'm betting on this because it doesn't seem we have a lot of 
> graphic-intensive applications with AppArmor profile that might feel
> a 
> hit due to disabled optional NVIDIA optimizations.

The AppArmor project doesn't nor does Ubuntu, Debian, OpenSUSE, Tails,
etc, but there are consumers of apparmor that absolutely do (ie, there
are a lot of games packaged as snaps, and snappy uses AppArmor).

> > Furthermore, as a user, if I had an nvidia card I would expect that
> > the
> > nvidia abstraction would allow 3D acceleration to work and it
> > sounds
> > like nvidia changed the way their shared memory works (again, I
> > don't
> > have an nvidia system and basing this on the fact that these
> > denials
> > are only showing up now). 
> 
> 3D acceleration works fine with denies. It is only a additional 
> optimization NVIDIA have implemented. It is even documented that it
> does 
> not work on systems like SELinux and GRSecurity.
> 
>  From "Disabling executable memory optimizations" [0]:
> 
> quote
> 
> By default, the NVIDIA driver will attempt to use optimizations
> which 
> rely on being able to write to executable memory. This may cause 
> problems in certain system configurations (e.g., on SELinux when the 
> "allow_execmem" boolean is disabled or "deny_execmem" boolean is 
> enabled, and on grsecurity kernels configured with
> CONFIG_PAX_MPROTECT). 
> When possible, the driver will attempt to detect when it is running
> on 
> an unsupported configuration and disable these optimizations 
> automatically. If the __GL_WRITE_TEXT_SECTION environment variable
> is 
> set to 0, the driver will unconditionally disable these
> optimizations.
> 
> end quote.
> 
> So, if they disable them on SELinux and/or grsecurity kernels, we
> could 
> disable it by ourselves for AppArmor cases. Again, 3D acceleration
> works 
> fine with these denies (I use home-grew Wine and Steam profiles
> without 
> allowing these).

With this information, I would then suggest adding comments to the
nvidia abstraction on the above. Then someone profiling blender could
see that and add the necessary rules to the blender profile for the
optimizations.

So yes, whenever we get deny overrides, we could add deny rules to the
nvidia abstraction to silence the denials, but not sooner IMO.

> 
> > I would instead suggest that *if* we wanted
> > to split these accesses, we do something more like:
> > 
> >   * abstractions/nvidia-strict: all the safe accesses
> >   * abstractions/nvidia: #include nvidia-strict plus less desirable
> >     accesses
> > 
> > In this manner, profiles continue to work with new nvidia accesses,
> > but
> >   profilers can choose to do something more strict if they desire.
> 
> So if profile includes `<abstractions/nvidia-strict>`, they would
> have 
> to add these
> `deny @{HOME}/#[0-8]* rwm`,
> `deny /tmp/.gl* rwm`
> manually, in addition to the include?

With what is available today, yes, but see above.

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20180208/ff53ba88/attachment.sig>