On Fri, Dec 27, 2013 at 01:13:32PM +0800, Aaron Lewis wrote: > Hi, > > Looks like on 2.6.32 kernel there was a bug with sys_symlink, > > I'm trying to monitor all symlinks that points to a specific dir, so I added: > > -a exit,always -F arch=b64 -S symlink -F success=1 -F dir=/secure > > But "ln -s /secure/file /tmp/file" doesn't trigger alert > And "cd /secure; ln -s /bin/ls" does. > > So I guess the auditing implementation is somehow incomplete? No, but your understanding of the symlinks does not match the reality. Symlink target is a _string_, not a location. It is resolved every time you traverse that symlink and result of such resolution depends upon the state of filesystem(s) at that moment. In other words, "symlink that points to a specific dir" is not well-defined. Moreover, consider the following example: ln -s foo/secure /tmp/bar Does the resulting symlink satisfy your condition? No? It doesn't resolve to anything, unless /tmp/foo existed already. Now ln -s / /tmp/foo and suddenly /tmp/bar resolves to /tmp/foo/secure, which resolves to /secure. At which point did an interesting symlink appear in that scenario? Note also that mv /tmp/a/b/c/ /tmp/x might very well have turned a symlink somewhere under /tmp/a/b/c/something/else into one that resolves to /secure - all it takes is something like "../../../../../../secure" as target. Would you have rename(2) scan the entire directory tree in search of such beasts? Worse, a symlink to /proc/self/cwd/secure will resolve to different things for different processes and simple cd / will suffice to turn it into something that will (for that process) resolve to /secure. And all of the above can be combined, of course. So if you need to prevent/catch the appearance of symlinks that will resolve to something in given directory, you are SOL. Symlinks simply do not work that way - the location some symlink resolves to is not a function of that symlink alone and unless you are seriously proposing to rescan the entire filesystem upon each rename(2) (and, worse yet, each chdir(2)), you can not catch the moment when such symlinks appear. Watching for creation of symlinks with bodies matching .*/secure(/.*|$) would theoretically be feasible, but it'll yield tons of false positives. And I seriously doubt that we want to open that can of worms, anyway - regex matching isn't something you want in the kernel *and* restricting to e.g. some subtree won't work - offending symlink could've been created anywhere. Logging all symlink(2) and filtering out non-interesting target names in userland is feasible right now, but you'll a) get your logs spammed to hell and back (symlink(2) isn't that rare a syscall) and b) even after filtering the rate of false positives (i.e. symlinks that might eventually resolve to something in /secure, but never will) will be quite high. Kernel-side filtering on substrings of symlink(2) target might deal with (a), but (b) can't be helped at all.

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