Bug in auditing of sys_symlink

[Alexander Viro]

On Tue, Dec 31, 2013 at 06:49:49PM +0800, Aaron Lewis wrote:
> Hi Alex,
> 
> Sorry, I didn't make it clear.
> 
> I need to protect all files under a directory, e.g /secure/
> 
> So if there's any newly created symlinks that points to files under
> that directory, e.g /secure/some_file, I will need to know.
> (/secure is not a symlink, but an existing directory)
> However "-a exit,always -F arch=b64 -S symlink -F success=1 -F
> dir=/secure" doesn't do the job.
> If I do "ln -s /secure/some_file /tmp/aa", no auditing log is generated

... because a symlink had been created in /tmp.

> So I suspect auditing on symlink isn't for the source file/directory,
> but the target "string".

The target string here is "/secure/some_file".

> If I do "ln -s /bin/ls /secure/new_file", an auditing log is generated.

... since that creates a symlink in /secure, symlink's target being
"/bin/ls".

> That's what I mean by "bug".

Check which directory is modified by your commands.  Really.  ls -l /secure
will change after the second one, but will remain unchanged after the first
one.

You can get notified when /secure is changed by symlink addition; you can
not get notifications whenever somewhere appears a symlink that would
resolve to something under /secure - see the posting upthread for the
reasons why that really can't be done.

BTW, ln(1) manpage is atrocious.  GNU variant suffers from the usual attitude
of GNU project towards manpages (they hate the need to be concise and
prefer info(1) to man(1)), but BSD variant isn't much better ;-/
An honest variant would have to contain something like "ln(1) conflates
two unrelated functionalities - creating extra links to existing files
and creation of symlinks.  The syntax is superficially similar in both
cases, but they would've been better off as separate commands."

The thing is, original ln(1) syntax imitates that of cp(1) - ln from to
takes an existing file ("from") and makes "to" a new name for the same
file.  Unlike cp(1), the file itself isn't copied - both directory
entries end up refering to the same object.  Other forms also imitate cp(1) -
just as you can say cp <bunch of files> directory, you can say
ln <bunch of files> directory.

ln -s is something entirely different.  ln -s target name creates a new
symlink with "target" as contents.  Target does *not* refer to a file;
it's just a string to be interpreted when pathname resolution steps into
name.

That creates a nasty source of confusion - in the normal case (ln old new)
we are making the file "old" show up elsewhere ("new"), but in ln -s old new
we are making a symlink "new" that points to string "old".  Note that
both cases invite the use of word 'target', but in completely different
meanings and applied to different ln(1) arguments ;-/