On Wed, 27 Oct 2004 11:34:45 EDT, James Morris said:
> If people want to stack these modules with SELinux, then their essential
> functionality should instead be incorporated into SELinux so they can be
> managed via SELinux policy.
Here's a little snippet from an LSM I have:
+int vtkit_follow_link (struct dentry *dentry, struct nameidata *nd)
+{
+ struct inode *i_target = dentry->d_inode;
+ struct inode *i_parent = dentry->d_parent->d_inode;
+
+ /* Here we check the following - If the symlink is in a world-writeable
+ * directory and the dir is mode +t, then we don't follow the symlink
+ * unless the target's UID matches either the directory's or the
+ * process's. In particular, we do *not* cut uid==0 a free pass...
+ *
+ * If you have world-write dirs w/o +t, you're on your own...
+ *
+ * Subtle - we don't bother checking S_ISLNK on the inode because
+ * we're only called if the inode has a follow_link() function....
+ */
+ if (security_safe_symlink &&
+ (i_parent->i_mode & S_ISVTX) && (i_parent->i_mode & S_IWOTH) &&
+ (i_parent->i_uid != i_target->i_uid) &&
+ (current->fsuid != i_target->i_uid)) {
+ printk(KERN_NOTICE "vtkit - rejecting symlink UID %d (dir UID %d) follow by PID %d (uid=%d, comm=%s)\n",
+ i_target->i_uid, i_parent->i_uid, current->pid, current->uid, current->comm);
+ return -EPERM;
+ }
+ return 0;
+}
(It's basically Solar Designer's "Don't follow a symlink out of a o+w directory"
patch. security_safe_symlink is a sysctl boolean).
How do you express that as an SELinux policy? Note that we do *not* care where
the directory is (and thus what it may end up labeled) - if it's o+w and +t,
we don't follow symlinks.
This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 10:48:52 PDT