R help - Aug 2023 - R library highcharter function highchart() execute with exception the apparmor read denied for /etc/passwd and /etc/group

On Tue, 8 Aug 2023 10:39:15 +0000
"Gu, Jay via R-help" <r-help at r-project.org> wrote:
>  Then I execute the function highchart() it always throw the
> exception that child process has died. And I checked the
> /var/log/kern.log and found below error:
> 
> Aug 7 08:37:50 ip-172-31-27-249 kernel: [2251703.494866] audit:
> type=1400 audit(1691397470.399:739): apparmor="DENIED"
> operation="open" profile="managedr-profile"
name="/etc/passwd"
> pid=159930 comm="R" requested_mask="r"
denied_mask="r" fsuid=1000
> ouid=0
It's not that terrible to let a program access /etc/passwd. It does
contain the list of the users, which is a privacy risk, true, but at
least the passwords are safely hashed and hidden away in /etc/shadow.

Searching the CRAN mirror on GitHub for "/etc/passwd" gives quite a
few
hits, and so does "getpwuid". There are likely other POSIX functions
that read /etc/passwd too. Any of highcharter's 68 dependencies could
be trying to read /etc/passwd directly or indirectly. (Could be fs,
could be some other package.)

If you run R -d gdb and let it crash, what does the backtrace say?

I think it's likely that the /etc/passwd access won't be easy to get
rid of, so if you don't want to give R access to it, you might want to
run it inside a container or a virtual machine.

-- 
Best regards,
Ivan

Hi Ivan,

I'm running the R within docker container. Do you have any idea about it?
Thanks!


Best Regards!
Jay Gu

-----Original Message-----
From: Ivan Krylov <krylov.r00t at gmail.com> 
Sent: Wednesday, August 9, 2023 3:15 AM
To: Gu, Jay via R-help <r-help at r-project.org>
Cc: Gu, Jay <j.gu at sap.com>
Subject: Re: [R] R library highcharter function highchart() execute with
exception the apparmor read denied for /etc/passwd and /etc/group

[You don't often get email from krylov.r00t at gmail.com. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]

On Tue, 8 Aug 2023 10:39:15 +0000
"Gu, Jay via R-help" <r-help at r-project.org> wrote:
>  Then I execute the function highchart() it always throw the
> exception that child process has died. And I checked the
> /var/log/kern.log and found below error:
>
> Aug 7 08:37:50 ip-172-31-27-249 kernel: [2251703.494866] audit:
> type=1400 audit(1691397470.399:739): apparmor="DENIED"
> operation="open" profile="managedr-profile"
name="/etc/passwd"
> pid=159930 comm="R" requested_mask="r"
denied_mask="r" fsuid=1000
> ouid=0
It's not that terrible to let a program access /etc/passwd. It does
contain the list of the users, which is a privacy risk, true, but at
least the passwords are safely hashed and hidden away in /etc/shadow.

Searching the CRAN mirror on GitHub for "/etc/passwd" gives quite a
few
hits, and so does "getpwuid". There are likely other POSIX functions
that read /etc/passwd too. Any of highcharter's 68 dependencies could
be trying to read /etc/passwd directly or indirectly. (Could be fs,
could be some other package.)

If you run R -d gdb and let it crash, what does the backtrace say?

I think it's likely that the /etc/passwd access won't be easy to get
rid of, so if you don't want to give R access to it, you might want to
run it inside a container or a virtual machine.

--
Best regards,
Ivan

On Wed, 9 Aug 2023 01:13:40 +0000
"Gu, Jay" <j.gu at sap.com> wrote:
> I'm running the R within docker container.
In that case (depending on the way the container is set up, of course),
your /etc/passwd shouldn't even be a privacy concern. It's most likely
identical that in other containers running R. You can read it yourself
(either by getting a separate shell inside the container or by running
readLines("/etc/passwd")) and check for identifying information. There
should be no harm in letting an R package read it.

If you are curious to know which part is trying to access it, we still
need a backtrace at the point where AppArmor crashes the process,
either from a core file or from a live process. (Other techniques are
fine too, but setting conditional breakpoints on open() and openat() is
more involved.)

-- 
Best regards,
Ivan