On Mon, 17 Jan 2005 23:45:56 +0530, Syed Ahemed said:
> For instance open() system call without the LSM patch checks for file
> attributes for read write permissions from the user .
> What does this "security_ops->file_permission (file, MAY_WRITE); "
> do additionally?
It does all the actual work.
> In short do i need to write "C code" to implement the security
> solution like checking if a file has symbolic link before opening to
> avoid race condition ?
You either write C code, or add in somebody else's C code (like SELinux)
to do the work.
Sample file_permission exit from a small LSM I wrote to do OpenWall-ish stuff:
+#ifdef CONFIG_SECURITY_SYMLINK
+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 byPID %d (uid=%d, comm=%s)\n",
+ i_target->i_uid, i_parent->i_uid, current->pid, current->uid, current->comm);
+ return -EPERM;
+ }
+ return 0;
+}
+#endif
This requires some "glue" code to create a security_ops structure, populate it
with a pointer to this function, and register it.
> Issue 2
> -----------
> Apart from modular implementation the reason i moved from LIDS patch
> without LSM --> LSM with OPENWALL/LIDS/SELINUX was because
> LIDS provides administrative control over files and process and not
> kernel level security . LIDS doesnt guarantee bufferover flow
> solution. Openwall/LSM does
Openwall doesn't do anything to protect against buffer overflows.
> 2] Does LSM with all its security modules(Open wall , LIDS, SELINUX
> )co-exist and IMPLEMENT a solution to buffer overflow , format
> strings and race conditions ?
LSM doesn't protect against coding errors in the kernel. It provides
a *framework* for programmers to use to implement additional security
checks for actions taken by userland programs.
The various modules don't co-exist well at all unless you pick up Serge Hallyn's
stacker patches - and even *then* you are *NOT* guaranteed that the various
LSM modules will "play nicely" together. Arbitrary composition of security
functions is a far-from-easily-done thing.
> What are the vulnerabilities that would remain if I dont use LIDS?
First off, we'd have to know what your threat model is - what are you trying
to protect against, and what *arent* you worried about?
This archive was generated by hypermail 2.1.3 : Mon Jan 17 2005 - 10:54:42 PST