Re: Bug in auditing of sys_symlink

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 ;-/