# Rkhunter+Lynis and terminals deleted files issues. [SOLVED]

## spidark

Hallo fellow Gentoo /Linux users.

I have some questions about a few deleted files on my Laptop system, that are still used by my two terminals emulators.

Rkhunter and Lynis complains about these files.

```
[13:11:59] Info: Starting test name 'deleted_files'

[13:12:00]   Checking running processes for deleted files    [ Warning ]

[13:12:00] Warning: The following processes are using deleted files:

[13:12:00]          Process: /usr/bin/lxterminal    PID: 3080    File: /tmp/vteOIXB7X
```

```
[13:19:42] Performing test ID LOGG-2190 (Checking deleted files in file table)

[13:19:42] Test: checking deleted files but are still in use

[13:19:42] Result: found one or more files which are deleted, but still in use

[13:19:42] Found deleted file: /tmp/vteOIXB7X

[13:19:42] Found deleted file: /tmp/vteMLXB7X

[13:19:42] Found deleted file: /tmp/vte8MXB7X

[13:19:42] Found deleted file: /tmp/vteG4OG7X

[13:19:42] Found deleted file: /tmp/vteKPSG7X

[13:19:42] Found deleted file: /tmp/vteJ7PG7X

[13:19:42] Suggestion: Check what deleted files are still in use and why. [LOGG-2190]
```

Googling around i found out that these files are being created by lxterminal and xfce4-terminal (scroll-back buffer).

It seems to some a Security issue,and to move  /tmp to its own directory.

Question 1) If i do not have /tmp an e separate partition, where does Gentoo create /tmp  e.g. Memory ??,I'm thinking the latter one.

Question 2) How to deleted these file so that Rkhunter and Lynis stops complaining about them ? (e.g. chrooting into gentoo and removing them )

I'm open for any suggestions.

Thanks in advanced.Last edited by spidark on Mon Nov 09, 2015 6:14 am; edited 1 time in total

----------

## cboldt

For rkhunter, create a "ALLOWPROCDELFILE=/usr/bin/lxterminal" in /etc/rkhunter.conf, or in /etc/rkhunter.conf.local

I have no familiarity with Lynis, so can't be of help there other than to say that it probably has a means to allow certain processes to create and use deleted files.

----------

## Hu

Files in /tmp are in the directory tmp.  If that is its own filesystem, then they are on the filesystem that is tmp.  If that is not its own filesystem, then they are in the tmp directory on the filesystem that holds /.  There are more elaborate possibilities with bind mounts, but you are probably not using bind mounts.

----------

## spidark

 *cboldt wrote:*   

> For rkhunter, create a "ALLOWPROCDELFILE=/usr/bin/lxterminal" in /etc/rkhunter.conf, or in /etc/rkhunter.conf.local
> 
> I have no familiarity with Lynis, so can't be of help there other than to say that it probably has a means to allow certain processes to create and use deleted files.

 

Hi cboldt,

I thought of your solution,but this only stops Rkhunter from reporting it, while Lynis stills complains, but both sees this as a security issue.

Strange thing,  looks like the list just keep growing , it looks like a permission issue, as if terminals are not permitted to remove those files.

 *Hu wrote:*   

> Files in /tmp are in the directory tmp.  If that is its own filesystem, then they are on the filesystem that is tmp.  If that is not its own filesystem, then they are in the tmp directory on the filesystem that holds /.  There are more elaborate possibilities with bind mounts, but you are probably not using bind mounts.

 

Hi Hu,

/tmp is on the filesystem, i do have a swap partition, that the system never use, so maybe i can turn this partition to /tmp.

Im probably not bind mounting, because i have no idea what that means , so i may have to google that one.

But still how to get rid of these files ?

Thank you Guys for your answers.

----------

## Hu

Deleted files are freed automatically when no program has the file open.

----------

## cboldt

I'm not sure you want to "get rid" of those files, and in fact, the error reported is that those files are already GONE from the filesystem, but still being used by some program.

Since you know what creates and uses those files, you likely don't have a security concern over them.  In general, "disappearing files" can be a security issue, a sign that some malevolent force is doing things without your knowledge, and trying to hide its tracks by removing the trace from the filesystem.

As for putting /tmp on its own partition, I think the basic purpose for this is to prevent a malevolent force from filling up the partition that contains /tmp and other (possibly working) directories.  /tmp is usually writable by anybody, which makes it susceptible to being filled by anybody.  None of my systems have /tmp on a separate partition (although it would be easy enough to have the contents of /tmp reside only in RAM by making an assignment in /etc/fstab:

```
tmpfs      /tmp     tmpfs    noatime        0 0
```

You might need to make uid and gid assignments there, if you want to have the contents of /tmp reside in RAM.  Just saying, you have a couple of separable issues here.  One being any security concern you have because /tmp shares disc space with other folders, and the other being reports from rkhunter and lynis that suggest a security breach, but you don't believe those reports actually represent security breaches, so you want rkhunter and lynis to ignore the fact that lxterminal is using deleted files.

----------

## cboldt

You asked where gentoo creates the /tmp directory.

/tmp is a directory off the root (/) directory, and as such is just a directory name on the root filesystem.  The CONTENTS of /tmp are usually in the same partition or filesystem that the root directory (/, not /root) is on.  But any directory off the root directory (/, not /root) can be assigned to some other partition, or in case of temproary/volatile contnets, assigned space in RAM.  /sys and /proc are examples of pseudo-filesystems that have directory names in the root directory (/, not /root), and just above I mentioned that /tmp could be too.

On my systems, /var/tmp/portage is a tmpfs (in RAM), and is the space that I've assigned for gentoo to compile programs.  /home is on its own partition, /usr is on its own partition, and /boot is on its own partition.  I also have a couple of "non-standard" directories off the root directory (/, not /root), those being /public and /backup.  Each of those has its own partition too.  I find that proliferation of partitions is overly complicated for what my systems are tasked with, but at the same time, it was worthwhile to learn how to set things up that way, and I don't see any benefit to reverting to fewer partitions.

My systems have that security risk of /tmp sharing disc space with other directories off the root directory (/etc, /misc, /root, /bin, /sbin, /lib, /opt).  The /tmp directory is available on a local network, but nobody here has a clue how to use it, so it doesn't get very big, less than 1 Mb on a machine that is the DNS, mail and print server (952 days uptime).

----------

## spidark

 *cboldt wrote:*   

> I'm not sure you want to "get rid" of those files, and in fact, the error reported is that those files are already GONE from the filesystem, but still being used by some program.
> 
> 

 

Hi cboldt,

I retrieved one of these files and try to check it contents, without any luck, just garbage, but that's the thing, its deleted and not yet deleted.

 *cboldt wrote:*   

>  Just saying, you have a couple of separable issues here. One being any security concern you have because /tmp shares disc space with other folders, and the other being reports from rkhunter and lynis that suggest a security breach, but you don't believe those reports actually represent security breaches, so you want rkhunter and lynis to ignore the fact that lxterminal is using deleted files.
> 
> 

 

Well to make Rkhunter ignore is easy , just adjust its config as you stated above.

I was not concerned because im the only user on this system which is a laptop , which i think is running pretty secured, but  better safe then sorry , because what's security these days anyway.

So googling i came across this LINK

So that got me spooked, ok a little spooked.

So after reading  that article i gave Rkhunter and Lynis reports a closer look.

The article also specify some solutions for spooked users as myself.

Lynis also states that you should check this.

[20:42:07] Suggestion: Check what deleted files are still in use and why. [LOGG-2190]

So i think my questions has been answered.

1 ) My  /tmp directory lives inside root / so these files are being created live on the disk.

2 ) I can however move /tmp to memory or to its own partition, and test if Rkhunter /Lynis still complains about these files.

Thank you Guys for your help and suggestions.

----------

## cboldt

Rkhunter and lynis are going to complain, regardless of the medium the contents of /tmp reside on.

If I thought terminal scrollback history being recorded to disk represented a security risk to information that I deem confidential, I'd follow the advice in the link you posted, and switch to a different terminal.  If the libVTE-based terminals were the only ones that I could stand to use, I'd mount /tmp on a tmpfs filesystem.  That way, the scrollback history is erased when the computer is shut down.  Not "perfect" security, but removes one vector of potential data leakage.

----------

## cboldt

Excluding selected files or processes from the lynis report of deleted files still in use will require editing the lynis code.

The relevant lynis routine can be found at https://github.com/CISOfy/lynis/blob/2.1.1/include/tests_logging, search for LOGG-2190.  You could probably find that routine on your system with `locate tests_logging`

lynis is running the command `lsof -n +L 1` and reporting the filenames that lsof delivers from that command.

You should try running `lsof -n +L 1` yourself, to see the output.  Once you see the output, and the lynis code in tests_logging, you might be able to figure out how to use an interposed `grep -v` (or `egrep -v`, if you have multiple exclusions)  to exclude certain programs from being included in the $FIND variable.  You can safely tinker with ideas on the command line, for example `lsof -n +L 1 | grep -v firefox` excludes reporting of deleted files in use by firefox.

----------

## spidark

 *cboldt wrote:*   

> Excluding selected files or processes from the lynis report of deleted files still in use will require editing the lynis code.
> 
> The relevant lynis routine can be found at https://github.com/CISOfy/lynis/blob/2.1.1/include/tests_logging, search for LOGG-2190.  You could probably find that routine on your system with `locate tests_logging`
> 
> lynis is running the command `lsof -n +L 1` and reporting the filenames that lsof delivers from that command.
> ...

 

Hi cboldt,

Some strange things happening on my Laptop with these deleted files.

I did not move the /tmp directory to its own partition, because i had the same feeling that same results would apair.

The strangest thing is that when i log into Gentoo,fire up lxterminal  and run the command 

```
sudo lsof -n +L 1 | grep deleted
```

.

There's no output, nothing nada, clean as a whistle.

But  if i run 

```
sudo rkhunter -c -sk
```

, and then 

```
sudo lsof -n +L 1 | grep deleted
```

, these deleted files shows up again.

I ran lynis and rkhunter about a thousand times now, never did i get a firefox or pcmanfm deleted file hit.

```
lxtermina  2877 spidark   13u   REG    8,2    12864     0  925595 /tmp/vte8VNN7X (deleted)

lxtermina  2877 spidark   14u   REG    8,2    30394     0  925596 /tmp/vteOFNN7X (deleted)

lxtermina  2877 spidark   15u   REG    8,2     7376     0  926114 /tmp/vteHGNN7X (deleted)

lxtermina  2877 spidark   16u   REG    8,2        0     0  936783 /tmp/vtePV1R7X (deleted)

lxtermina  2877 spidark   17u   REG    8,2        0     0  936784 /tmp/vte5S1R7X (deleted)

firefox    2898 spidark   45u   REG    8,2      512     0 1705724 /var/tmp/etilqs_aU4qF4LQrZkRjL7 (deleted)

firefox    2898 spidark   46u   REG    8,2    32768     0 1745078 /var/tmp/etilqs_Im9KDBPAknmWrrd (deleted)

xfce4-ter 29137 spidark   13u   REG    8,2     8384     0  936780 /tmp/vtePICR7X (deleted)

xfce4-ter 29137 spidark   14u   REG    8,2    22400     0  936781 /tmp/vteLFCR7X (deleted)

xfce4-ter 29137 spidark   15u   REG    8,2     7392     0  936782 /tmp/vteRGCR7X (deleted)
```

I can retrieve the file i want  by running 

```
 cd /proc/2898/fd
```

and 

```
cp -v 45 /home/spidark/Documents/firefox.saved
```

Text editors can't read the contents of these files, abiword tries, but its loaded with garbage.

I do not know what 45u means yet, i have to look that up in the man page, but i do know that the contents of e.g.

```
pcmanfm    2783 spidark   13r   REG    8,4    64936     0  131186 /home/spidark/.local/share/gvfs-metadata/home (deleted)

pcmanfm    2783 spidark   14r   REG    8,4    32768     0  131207 /home/spidark/.local/share/gvfs-metadata/home-7cab36ae.log (deleted)
```

can be read with abiword, im guessing 13r means its a readable file

So im back where i started, still no clue to whats really going on here.

I understand that the files are deleted, at least thats what rkhunter and lynis states.

But if i can retrieve those files so can others.

In this case I'm running a laptop, and there no other users logged in, but this can be a security issue if /tmp is indeed writable/readable by everyone.

I'm going to sleep on this one, and check back tomorrow.

Thanks you  cboldt and Hu for your input /feedback on this matter.

----------

## cboldt

Maybe the "appearing" (but deleted) scrollback files come into place when there is some scrollback, but not before.  That rkhunter command delivers a substantial amount of output, which is available to scrollback into, even if you don't.

I don't see any purpose for the `| grep deleted` part of your tinkering around command lines.  The only output suppressed by that is the top line of the lsof output.

Interesting mystery that you haven't seen reports of deleted files from firefox or pcmanfm from previous runs of at least lynis (which uses lsof directly for that test).  Those files aren't considered "deleted but in use" when the parent program is closed,  but I assume from your puzzlement that you had firefox and pcmanfm running when the past lynis and rkhunter tests were run.

Use `strings` to ferret out readable stuff.  After you cd to the /proc/PID/fd folder of interest, `strings 45` (using your example, PID 2898 being firefox, and file descriptor 45 being assigned to /var/tmp/etilqs_aU4qF4LQrZkRjL7).

In the lsof output, 13r, 14r indicate the file descriptor number (you can also see the relationship between fd number and filename if you run `ls -l /proc/2898/fd`) plus a letter.  Reading the man page of lsof, the letter indicate the mode that the file is opened in, which is not the same thing as the permissions on a file.  A file with read/write permissions can be opened read only, or write only, or read and write.  The lsof report tells how the file is opened, not what permissions the file has.  "u" means the file is open read/write.

I haven't given much thought into how to secure /proc, beyond what happens "naturally" whatever the default configurations are.  I see that the file permissions there are the same as my UID and GID.

----------

## spidark

 *cboldt wrote:*   

> Maybe the "appearing" (but deleted) scrollback files come into place when there is some scrollback, but not before.  That rkhunter command delivers a substantial amount of output, which is available to scrollback into, even if you don't.
> 
> 

 

Your right, this got me thinking, what if a set scroll back line buffer to NULL, or 0 in lxterminal, and wallah no more vte temp files creations, at least with lxterminal.

 *cboldt wrote:*   

> I don't see any purpose for the `| grep deleted` part of your tinkering around command lines.  The only output suppressed by that is the top line of the lsof output.

 

N00b thinggie, filtering on deleted i think.

 *cboldt wrote:*   

> 
> 
> Interesting mystery that you haven't seen reports of deleted files from firefox or pcmanfm from previous runs of at least lynis (which uses lsof directly for that test).  Those files aren't considered "deleted but in use" when the parent program is closed,  but I assume from your puzzlement that you had firefox and pcmanfm running when the past lynis and rkhunter tests were run.

 

Yes they where indeed running,for some unknown reason i always run forensic software without anything running in the background.

 *cboldt wrote:*   

> 
> 
> Use `strings` to ferret out readable stuff.  After you cd to the /proc/PID/fd folder of interest, `strings 45` (using your example, PID 2898 being firefox, and file descriptor 45 being assigned to /var/tmp/etilqs_aU4qF4LQrZkRjL7).

 

I did and was surprised to see every single command that was typed into the Terminal in that (14u) file.

As soon as there is Scroll back, 3 files are created instantly.

```

spidark@darknet /proc/3122/fd $ sudo lsof -n +L 1 

COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NLINK   NODE NAME

lxtermina 3122 spidark   13u   REG    8,2      976     0 926119 /tmp/vte39DJ7X (deleted)

lxtermina 3122 spidark   14u   REG    8,2     1424     0 926120 /tmp/vteC6DJ7X (deleted)

lxtermina 3122 spidark   15u   REG    8,2      448     0 928019 /tmp/vteM2DJ7X (deleted)

```

File number 13 and 15 are unreadable by strings but 14 is.

If you check the Output below you can see me SU ing into the system.

The password is not echoed back on screen which is a good thing.

But what if for some reason you accidentally typed your root password into that terminal emulator.

That password will also be visible in that tmp file.

This is the part where my N00bness kicks in,can other users see your processes ??

IF they can ?

Can they access that file?

I'm thinking they cant because of the sticky bit on /tmp file.

Correct me if I'm wrong here, its interesting stuff to me.

```
spidark@darknet /proc/3122/fd $ su

Password: 

darknet fd # pam_tally2 --reset -u spidark

Login           Failures Latest failure     From

spidark                0    

darknet fd # exit

exit

```

But for now, i just set scroll back buffer lines to NULL or 0 to avoid this.

But  thanks again.

And if you have more educational feedback, i like to hear more.  :Very Happy: 

----------

## cboldt

The sticky bit doesn't prevent reading by others, what does that is file permissions and the GID and UID of the file.

/proc is readable by everybody, but the /proc/PID directory is only readable by the user who started that particular PID.

Do either `stat /proc/PID/fd` or `ls -l /proc/PID` to see the ownership and permissions on the fd folders.  Another way to see this effect is to do `ls /proc` as spidark, then the same command as root.  spidark should NOT see PID "1" at all, because spidark doesn't have any permissions on PID 1.

The short version, other users cannot see your processes in /proc - but it's worthwhile to prove it to yourself, because learning how to check in this case might be useful in other/different cases.

Thanks for clearing up the appearance of deleted files by firefox sometimes, but not in the many times you ran forensics in the past, and for the education on when the deleted files are created by lxterminal.

It would be easy to put /tmp on a tmpfs, which is one of the suggestions made in the bugreport you linked to previously.  That keeps the scrollback out of persistent storage.  Wouldn't be a concern for me because I don't relinquish control over drives that I take out of service, but if I had a program that wrote scrollback to /tmp, I'd still take that step to minimize proliferation of the locations of potentially sensitive information.

----------

## cboldt

 *Quote:*   

> N00b thinggie, filtering on deleted i think. 

 

That's what your grep command was doing, but "+L1" on lsof does the same thing, so the grep command is redundant except for getting rid of the top line of lsof output.  Doesn't make much difference on command line tinkering, who cares if that is efficient   :Smile:  , but if you were contemplating changes to the lynis code, it's worthwhile to eliminate redundancies.

----------

## spidark

 *cboldt wrote:*   

> The sticky bit doesn't prevent reading by others, what does that is file permissions and the GID and UID of the file.
> 
> 

 

A Man page or Google Material , noted cboldt.  :Laughing: 

 *Quote:*   

> 
> 
> /proc is readable by everybody, but the /proc/PID directory is only readable by the user who started that particular PID.
> 
> Do either `stat /proc/PID/fd` or `ls -l /proc/PID` to see the ownership and permissions on the fd folders.  Another way to see this effect is to do `ls /proc` as spidark, then the same command as root.  spidark should NOT see PID "1" at all, because spidark doesn't have any permissions on PID 1.
> ...

 

Yes i did the test's, indeed user spidark cannot see PID 1 , only root can see that process, also /proc/xxx/fd is only readable by the owner of the process  :Very Happy: 

```
spidark@darknet /proc/3042/fd $ ls -al /proc/

total 4

dr-xr-xr-x 152 root root     0 Nov  8 20:21 .

drwxr-xr-x  21 root root  4096 Nov  8 20:10 ..

..........................................etc

dr-x------   8 spidark spidark     0 Nov  8 20:24 3042

spidark@darknet /proc/3042/fd $ stat /proc/3042/fd

  File: ‘/proc/3042/fd’

  Size: 0            Blocks: 0          IO Block: 1024   directory

Device: 4h/4d   Inode: 10467       Links: 2

Access: (0500/dr-x------)  Uid: ( 1000/    spidark)   Gid: ( 1000/    spidark)

Access: 2015-11-08 20:24:14.262008433 +0100

Modify: 2015-11-08 20:24:14.262008433 +0100

Change: 2015-11-08 20:24:14.262008433 +0100

 Birth: -
```

 *Quote:*   

> 
> 
> Thanks for clearing up the appearance of deleted files by firefox sometimes, but not in the many times you ran forensics in the past, and for the education on when the deleted files are created by lxterminal.
> 
> 

 

Your welcome, I never noticed any deleted file from firefox or any other running software before, but i guess it was just pure luck.

 *Quote:*   

> 
> 
> It would be easy to put /tmp on a tmpfs, which is one of the suggestions made in the bugreport you linked to previously.  That keeps the scrollback out of persistent storage.  Wouldn't be a concern for me because I don't relinquish control over drives that I take out of service, but if I had a program that wrote scrollback to /tmp, I'd still take that step to minimize proliferation of the locations of potentially sensitive information.

 

Moving /tmp to tmpfs or own partition.

Thanks cboldt for your patience , time and your input and feedback.

I guess a can mark this post as SOLVED.

Thanks  :Wink: 

----------

