Run iped as unprivileged user

[mobab-th]

I think it is better to run IPED inside the container as an unprivileged user. The results of the processing can be used as a normal user. At least in Linux environments this is better than correcting the access rights or running the analysis as root user. The folder for the IPED installation could be /opt/iped instead of /root/iped.

[arisjr]

Nice idea.

I will implement it on a future version of IPED.

[arisjr]

I did implement this feature in the latest iped docker (ipeddocker/iped:latest). It's not a release yet cause it needs more testing.

For running the container as the current user, you just need to add the following environment variable in your already existent "docker run" command line: -e USERID=${UID}

If you want to run the container as another user other than yours, ou just need to change the UID for your target UID.

Please test this feature for me to close this issue.

[mobab-th]

E01-Files are not read in. Error according to log:

2023-03-02 10:09:51 [INFO]  [engine.sleuthkit.SleuthkitClient$2]            SleuthkitServer 1: at iped.engine.config.Configuration.configureLogger(Configuration.java:86)
    at iped.engine.config.Configuration.getConfiguration(Configuration.java:101)
    at iped.engine.config.Configuration.loadConfigurables(Configuration.java:166)
    at iped.engine.config.Configuration.loadConfigurables(Configuration.java:143)
    at iped.engine.sleuthkit.SleuthkitServer.main(SleuthkitServer.java:71)
java.lang.Exception: Error starting SleuthkitServer 1
    at iped.engine.sleuthkit.SleuthkitClient.start(SleuthkitClient.java:219)
    at iped.engine.sleuthkit.SleuthkitClient.<init>(SleuthkitClient.java:166)
    at iped.engine.sleuthkit.SleuthkitClient$1.run(SleuthkitClient.java:141)

[arisjr]

Please, send command line and full log, if possible.

[mobab-th]

command line:

podman run --rm -it \ -e TZ="Europe/Berlin" \ -e iped_indexTempOnSSD=true \ -e iped_outputOnSSD=true \ -e iped_Examiner=tester \ -e iped_enableCarving=false \ -e iped_numThreads=16 \ -e iped_enableLanguageDetect=true \ -e iped_enableOCR=true \ -e iped_OCRLanguage=eng+deu+frk \ -e iped_phone_region=DE \ -e iped_enableNamedEntityRecogniton=true \ -e iped_enableAudioTranscription=false \ -e iped_enableImageSimilarity=true \ -e iped_enableFaceRecognition=false \ -e iped_indexUnallocated=false \ -e iped_addUnallocated=false \ -e iped_skipHashDBFiles=true \ -e iped_excludeKnown=true \ -e ipedlocale=de-DE \ -v $(pwd):/evidences \ -v /cases/:/cases \ -v /home/tester/hashdb/:/mnt/hashesdb \ -v $HOME/.iped/plugins:/mnt/plugins \ localhost/ipeddocker/iped:processor4.1.0 java -jar /opt/IPED/iped/iped.jar --nogui \ --portable \ -log /cases/$(date +%Y%m%d%H%M%S)-narcos.log \ -d /evidences/narcos01.E01 \ -o /cases/narcos

Log 20230302_131226-narcos.log

run with -e USERID=${UID}

i get an permission denied error on output path

[arisjr]

Thanks for your report.

please, use the "docker.io/ipeddocker/iped:processor" without the version, I didn´t made a release for it yet - it has no version, so you have to use the latest, that has the latest changes.

I have tested your command line against the latest processor and all went well, but my configuration is linux+docker.

Are you running podman on windows + wsl? podman can be tricky on wsl. I have one workstation configured like that and will test it later today.

Does your current user have write permission to /cases folder?

As a final observation about your command line, --portable is only efficient when you put the output folder on the same directory of the evidence file. @lfcnassif, can you confirm that?

My command line (adjusted for my environment) follows bellow:

dkr -w "`pwd`" -e USERID=${UID} -e TZ="Europe/Berlin" -e iped_indexTempOnSSD=true \
      -e iped_outputOnSSD=true -e iped_Examiner=tester -e iped_enableCarving=false \
      -e iped_numThreads=16 -e iped_enableLanguageDetect=true -e iped_enableOCR=true \
      -e iped_OCRLanguage=eng+deu+frk -e iped_phone_region=DE \
      -e iped_enableNamedEntityRecogniton=true -e iped_enableAudioTranscription=false \
      -e iped_enableImageSimilarity=true -e iped_enableFaceRecognition=false \
      -e iped_indexUnallocated=false -e iped_addUnallocated=false -e iped_skipHashDBFiles=true \
      -e iped_excludeKnown=true -e iped_locale=de-DE \
      -v ./plugins:/mnt/plugins \
      ipeddocker/iped:processor java -jar /opt/IPED/iped/iped.jar --nogui \
           --portable -d teste-ext4.ewf.E01 -o TESTE-EWF -log $PWD/TESTE-EWF.log

[lfcnassif]

As a final observation about your command line, --portable is only efficient when you put the output folder on the same directory of the evidence file. @lfcnassif, can you confirm that?

Almost that. --portable works if output and evidence are on the same volume/mount point, so we can build relative paths. It will be used for other things soon: https://github.com/sepinf-inc/IPED/issues/1142

PS: By the way, running IPED as an unprivileged user is highly recommended, since we process untrusted data from the wild, that may contain some exploit to try to explore some vulnerability (like the famous log4j one).

[arisjr]

I just tested the iped container with PODMAN and discovered what are the @mobab-th problems.

First we have to make clear that, using DOCKER, all IPED tests worked - with or without unprivileged user setting (with or without the USERID environment variable setting).

Now lets talk about PODMAN.

Differently from DOCKER (that needs a service running as root, and we have to lower the user privilege for running the application - or run it as root), PODMAN permits that containers be run directly with the privilege of the current user, and, plus, has a lot of security enforcements for this running container.

So, that said, we have two scenarios for running IPED with PODMAN using unprivileged users:

1. Running as the system root user (making sudo), and inside the docker, lowering the privilege of the user running the application ($ sudo podman run --rm -it -e USERID=1000 docker.io/ipeddocker/iped:processor ...)
2. Running as a normal user, without lowering the container user privileges (without the environment variable USERID). Inside the container it will be like it is running as root, but the effective user privilege it uses is the running user ID ($ podman run --rm -it docker.io/ipeddocker/iped:processor ...). If, when running as unprivileged user, one tries to lower user privileges with USERID variable, PODMAN creates a different effective UID, mapping to a high number not present in the system (and on the file system ACLs also), for example UID 1000 is mapped to 100999, causing the permission errors that @mobab-th had.

This problem is solved.

But there is another problem happening, I think that is caused by the security enforcements that appear when running IPED with PODMAN: IPED is unable to start or communicate with the servers needed by robustImageReading. This cause the other error that @mobab-th had (and I had it too on my tests).

2023-03-02 10:09:51 [INFO]  [engine.sleuthkit.SleuthkitClient$2]            SleuthkitServer 1: at iped.engine.config.Configuration.configureLogger(Configuration.java:86)
    at iped.engine.config.Configuration.getConfiguration(Configuration.java:101)
    at iped.engine.config.Configuration.loadConfigurables(Configuration.java:166)
    at iped.engine.config.Configuration.loadConfigurables(Configuration.java:143)
    at iped.engine.sleuthkit.SleuthkitServer.main(SleuthkitServer.java:71)
java.lang.Exception: Error starting SleuthkitServer 1
    at iped.engine.sleuthkit.SleuthkitClient.start(SleuthkitClient.java:219)
    at iped.engine.sleuthkit.SleuthkitClient.<init>(SleuthkitClient.java:166)
    at iped.engine.sleuthkit.SleuthkitClient$1.run(SleuthkitClient.java:141)

So I suggest, for using IPED container with PODMAN, until this issue get solved, to use the variable iped_robustImageReading set to false on all cases. To simplify, I would run podman as the current user. ($ podman run --rm -it -e iped_robustImageReading=false ...)

I've made some tests disabling robustImageReading and all worked perfectly (Windows+WSL+podman). Waiting for @mobab-th to test.

@lfcnassif, is robustImageReading defaults is set to true now? That's what is happening on 4.1.0 release. Also, how do robustImageReading servers work and how they communicate? I need to know this to address the limitation that PODMAN imposes.

[lfcnassif]

@lfcnassif, is robustImageReading defaults is set to true now? That's what is happening on 4.1.0 release. Also, how do robustImageReading servers work and how they communicate? I need to know this to address the limitation that PODMAN imposes.

Its default is true since version 4.0. It isolates rare errors from Sleuthkit that cause the process to be killed by OS, like SIGSEGV. It also helps to read image contents in parallel, because Sleuthkit use a lock to read E01 and APFS contents. Communication uses process stdout/stdin for coordination and memory mapped files for fast IPC data transfer. Not sure what version you are testing, but above errors may point to this line called from the external processes: https://github.com/sepinf-inc/IPED/blob/master/iped-engine/src/main/java/iped/engine/config/Configuration.java#L86

[mobab-th]

PODMAN permits that containers be run directly with the privilege of the current user,

That's one reason why I switched to PODMAN on my Debian machine. So the USERID-Parameter is useless in PODMAN. Sorry, was my mistake.

-e iped_robustImageReading=false

Reading of E01-files works in PODMAN with that.

[arisjr]

That's one reason why I switched to PODMAN on my Debian machine. So the USERID-Parameter is useless in PODMAN. Sorry, was my mistake.

You can still use USERID to drop even more privileges - this way, in case of a problem, there will be difficulty to write even on your current user environment. But you will have to permit everyone write permissions on your /cases folder anyways, I think - I don't know how to control the effective user ID mapping on PODMAN yet.

Reading of E01-files works in PODMAN with that.

So I will close this feature request and open an issue for robustImageReading support on podman.

Cheers.