Re: Unexpected security(8) output
Hi Craig,
Craig Skinner wrote on Thu, Feb 01, 2018 at 06:15:02PM +:
> This is something I put in /etc/daily.local
>
> SUIDSKIP=$(mount | awk '/nosuid/ { print $3 }')
On your own system, fair enough.
In the official script, i would rather not exclude such file systems
because it seems useful to be alerted if something creates SUID files
in file systems mounted nosuid, like in /var/.
Besides, some people may have a file system mounted nosuid but not
nodev, and your scheme also disables the checks for device nodes.
Yours,
Ingo
Re: Unexpected security(8) output
Hi folks,
On Fri, 26 Jan 2018 11:30:56 -0700 Andrew Hewus Fresh wrote:
> ...
> You could add your home directory to the SUIDSKIP environment variable
> in /etc/daily.local to avoid searching there if this message keeps
> annoying you and you don't care about devices and suid changes there.
>
> http://man.openbsd.org/security#SUIDSKIP
Thanks Andrew.
The daily disk I/O might be reduced by having a look at the output of:-
$ mount | awk '/nosuid/ { print $3 }'
$ awk '/nosuid/ { print $2 }' /etc/fstab
This is something I put in /etc/daily.local
SUIDSKIP=$(mount | awk '/nosuid/ { print $3 }')
Cheers,
--
Craig Skinner | http://linkd.in/yGqkv7
Re: Unexpected security(8) output
Hi Clint,
Clint Pachl wrote on Fri, Jan 26, 2018 at 10:43:47AM -0700:
> I received the following output from security(8):
>
> Running security(8):
> Can't
> opendir(/home/pachl/.cache/mozilla/seamonkey/e8cxa4g0.default/safebrowsing-backup):
> No such file or directory at /usr/libexec/security line 594.
>
> I didn't realize security parses through user files; beyond a few dot
> files.
It does so to find SUID/SGID files and special files, see the
function find_special_files().
Messages like the one you encountered are rare, and it would be hard
to suppress them without introducing a risk to hide actual problems.
> I don't understand perl. Is the script keeping state somewhere?
Yes, in /var/backups/{setuid,device}.{current,backup}, see the
function check_filelist() for details.
I just looked at what we wrote in the security(8) manual.
In the DESCRIPTION, we say:
* Check for changes in setuid/setgid files and devices.
* Check for changes in the device file list.
Below FILES, /var/backups is listed, without any further details.
I guess the documentation is good enough. As a rule, users are not
required to worry about the details of the algorithm or bookkeeping,
the script is supposed to just work and speak up if it notices anything
fishy. If somebody is curious, they can inspect the code, it is not
very long.
> How did it know to even try opening the safebrowsing-backup directory?
It looks everywhere because dangerous special files might hide anywhere.
It uses File::Find(3p) to do so.
Arguably, part of these checks have become less important since
we are mounting /home/ and other directories nodev and nosuid
by default. Then again, finding weird files in weird places is
still weird and should maybe still be noted. In any case,
restricting the search would complicate matters and increase the
risk of missing something relevant.
> The missing directory isn't listed in /etc/changelist or
> /etc/mtree/{special,*.secure}. I couldn't find any trace of it in /var/.
>
> So I manually ran the security script again. It returned no output.
The file of the name you quote above probably was a dead symbolic
link; it may only have existed for a short time, for example while
your browser was shuffling stuff around. Your seamonkey likely
removed it before your manual run - programs are kind of expected
to create and delete files in their own cache directories.
> I'm confused.
> Can anyone explain this?
I tried, with a bit of guessing.
Yours,
Ingo
Re: Unexpected security(8) output
On Fri, Jan 26, 2018 at 10:43:47AM -0700, Clint Pachl wrote: > I received the following output from security(8): > > Running security(8): > Can't > opendir(/home/pachl/.cache/mozilla/seamonkey/e8cxa4g0.default/safebrowsing-backup): > No such file or directory at /usr/libexec/security line 594. That likely comes from the File::Find inside of find_special_files where security(8) looks for changed setuid files and devices. Most likely that cache directory was cleaned up between reading the directory listing of the parent and actually trying to recurse into that directory. You could add your home directory to the SUIDSKIP environment variable in /etc/daily.local to avoid searching there if this message keeps annoying you and you don't care about devices and suid changes there. http://man.openbsd.org/security#SUIDSKIP l8rZ, -- andrew - http://afresh1.com Instructions are just another man's opinion of how to do something. -- Weldboy #DPWisdom
Unexpected security(8) output
I received the following output from security(8):
Running security(8):
Can't
opendir(/home/pachl/.cache/mozilla/seamonkey/e8cxa4g0.default/safebrowsing-backup):
No such file or directory at /usr/libexec/security line 594.
I didn't realize security parses through user files; beyond a few dot
files. I don't understand perl. Is the script keeping state somewhere?
How did it know to even try opening the safebrowsing-backup directory?
The missing directory isn't listed in /etc/changelist or
/etc/mtree/{special,*.secure}. I couldn't find any trace of it in /var/.
So I manually ran the security script again. It returned no output. I'm
confused.
Can anyone explain this?
Thank you,
Clint
