Bug in auditing of sys_symlink

[Aaron Lewis]

Hi Alex,

Thanks for the excellent explanation.  I've also checked how file
system stores a symbolic link after reading your post.
Now I know why symlink doesn't work as  I thought ;-P

On Wed, Jan 1, 2014 at 2:29 AM, Alexander Viro <aviro at redhat.com> wrote:
> 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 ;-/



-- 
Best Regards,
Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/
Finger Print:   9F67 391B B770 8FF6 99DC  D92D 87F6 2602 1371 4D33