Re: Security hooks, "standard linux security" & embedded use
On Thu, Jul 12, 2001 at 09:35:20PM +0400, Hans Reiser wrote: > Hi Linda, > > This seems very much in line with what Reiser4 is doing for DARPA, and what SE Linux >is doing for > the NSA. Or at least what Linus told the SE Linux folks he would like them to >write.:-) > > I am quite supportive of what you advocate generally, and I look forward to >cooperating with you in > the details. The details can be currently found in the most recent patch against 2.4.6 at: http://lsm.immunix.org/patches/lsm-2001_07_06-2.4.6.patch.gz There's a bit more information available, including the latest version of the patch at all times, available as a bitkeeper repository at: http://lsm.immunix.org/ thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Security hooks, "standard linux security" & embedded use
Hi Linda, This seems very much in line with what Reiser4 is doing for DARPA, and what SE Linux is doing for the NSA. Or at least what Linus told the SE Linux folks he would like them to write.:-) I am quite supportive of what you advocate generally, and I look forward to cooperating with you in the details. May I suggest we contact the SE Linux folks, and each of our teams establish a point-of-contact to work on developing the details of what needs to be done? We call your security hooks "security plugins" or "secplugs" in Reiser4, mostly to identify that they are a component of the Reiser4 "plugin" approach to extensibility. Reiser4 is getting underway this month. We are willing to adapt our terminology and coding to be be consistent with yours. We don't really have a need to be the leaders in this area. We just need to get the job done, and to ensure that nothing that is done crimps our ability to accomplish our objectives. Our project objectives are somewhat describable as "make it easy for folks like the NSA and the DoD to add new security features to Reiser4 by building the infrastructure for them." We will ship one implementation on top of that infrastructure that will implement ACLs, but we are more interested in enabling others than in doing ourselves. If the NSA or SGI wants to lead us a bit on this, that is fine with us. Our main insistence is going to be that the hooks should be very general, but I suspect you and the NSA also want that. We also need to have coding completed in ~8 months, so that it can all be debugged and stable and sent to Linus by Sep. 30th of next year. Do you have a list of all the hooks, etc., yet? Do you have anything like a general architecture for, given some vfs operation, and given some pluginid indicating object type, and given some secplugid (e.g. it might be the id of a secplug implementing an ACL), have the plugin check that the operation is allowable by calling the secplug (security hook) indicated by the secplugid? I think what is needed is an MxN matrix of security checks, where M is the number of vfs operations, and N is the number of secplugs. I am open to the idea that it should be MxNxO, where O is the number of security policies, though I don't plan to personally implement more than one security policy to ship with Reiser4 by default because I am pretty lazy. It won't surprise me if I end up shipping only one secplug with reiser4 initially (probably one implementing something embodying NT ACLs and unix permissions), and leave it to others to add the rest of them). I am quite supportive of your notion that some users have no need at all for security, and that they should be allowed a lightweight solution for their needs, though I will leave it to them to write that on top of the infrastructure I/we give them.:-) I envision the VFS operation invoking the plugin which invokes the secplug whose implementation varies with the choice of security policy compiled in. I don't honestly see the real usage critical need for dynamic loading of security policy modules, but I can yield on this if you see the need and code it since it probably isn't complex to code. I do like the idea of all of the code implementing a given security policy being isolated into its own single file/directory. Do you have any ideas on how to export to user space the ability to query what the permissions are, given that the permissions are being abstracted like this? I got your email, but I wasn't on the to: or cc: list. This confused me, so I invented a to: list that should reach all those likely to be interested in this. I am guessing this will be okay with you. Best, Hans LA Walsh wrote: > > Dear Linus et al., > > Sorry for the 'form' letter instead of individual names, but I > didn't want to have to send this out separately to every kernel developer > I know on LKML. > > I am asking for your input on the concept of moving the standard > Linux security checks into a "Linux Security Module". > > Discussion has come up on the Linux Security Module list > about whether or not the current linux security (file mode bits, uid > checking, etc.) should be modularized in the development of an LSM > framework implementation > > This would entail moving all of the standard checks out of the > kernel into a "standard security" module that, by default, would be > the security policy selected and compiled in during kernel configuration > and build. > > This seems to us (@sgi) to be the best solution to allow a > completely configurable security policy. This option allows > a policy creator complete flexibility in how or whether or not > existing security is called. For example, in POSIX 1e style Mandatory > Access Control, the information in the inode is also part of the > protected object. So if a process doesn't have access under MAC, the > DAC checks wouldn't even be executed since it
[PATCH] speedup reiserfs O_SYNC and fsync
Hello everyone,
This patch makes reiserfs O_SYNC and fsync faster by only
committing the last transcation a file/dir was included in,
instead of forcing a commit on the current transaction.
More speedups are still possible, this patch is fairly conservative.
It is based on 2.4.7-pre6 + the direct->indirect target flushing
patch I just sent. More testers would be greatly appreciated ;-)
Note, this changes the reiserfs in-core inode. modules users need
to recompile the whole kernel.
-chris
diff -Nru a/fs/reiserfs/dir.c b/fs/reiserfs/dir.c
--- a/fs/reiserfs/dir.c Thu Jul 12 10:46:26 2001
+++ b/fs/reiserfs/dir.c Thu Jul 12 10:46:26 2001
@@ -47,22 +47,10 @@
};
int reiserfs_dir_fsync(struct file *filp, struct dentry *dentry, int datasync) {
- int ret = 0 ;
- int windex ;
- struct reiserfs_transaction_handle th ;
-
lock_kernel();
-
- journal_begin(, dentry->d_inode->i_sb, 1) ;
- windex = push_journal_writer("dir_fsync") ;
- reiserfs_prepare_for_journal(th.t_super, SB_BUFFER_WITH_SB(th.t_super), 1) ;
- journal_mark_dirty(, dentry->d_inode->i_sb, SB_BUFFER_WITH_SB
(dentry->d_inode->i_sb)) ;
- pop_journal_writer(windex) ;
- journal_end_sync(, dentry->d_inode->i_sb, 1) ;
-
- unlock_kernel();
-
- return ret ;
+ reiserfs_commit_for_inode(dentry->d_inode) ;
+ unlock_kernel() ;
+ return 0 ;
}
diff -Nru a/fs/reiserfs/file.c b/fs/reiserfs/file.c
--- a/fs/reiserfs/file.cThu Jul 12 10:46:26 2001
+++ b/fs/reiserfs/file.cThu Jul 12 10:46:26 2001
@@ -50,6 +50,7 @@
lock_kernel() ;
down (>i_sem);
journal_begin(, inode->i_sb, JOURNAL_PER_BALANCE_CNT * 3) ;
+reiserfs_update_inode_transaction(inode) ;
#ifdef REISERFS_PREALLOCATE
reiserfs_discard_prealloc (, inode);
@@ -83,10 +84,7 @@
int datasync
) {
struct inode * p_s_inode = p_s_dentry->d_inode;
- struct reiserfs_transaction_handle th ;
int n_err = 0;
- int windex ;
- int jbegin_count = 1 ;
lock_kernel() ;
@@ -94,14 +92,9 @@
BUG ();
n_err = fsync_inode_buffers(p_s_inode) ;
- /* commit the current transaction to flush any metadata
- ** changes. sys_fsync takes care of flushing the dirty pages for us
- */
- journal_begin(, p_s_inode->i_sb, jbegin_count) ;
- windex = push_journal_writer("sync_file") ;
- reiserfs_update_sd(, p_s_inode);
- pop_journal_writer(windex) ;
- journal_end_sync(, p_s_inode->i_sb,jbegin_count) ;
+
+ reiserfs_commit_for_inode(p_s_inode) ;
+
unlock_kernel() ;
return ( n_err < 0 ) ? -EIO : 0;
}
diff -Nru a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
--- a/fs/reiserfs/inode.c Thu Jul 12 10:46:26 2001
+++ b/fs/reiserfs/inode.c Thu Jul 12 10:46:26 2001
@@ -41,6 +41,7 @@
down (>i_sem);
journal_begin(, inode->i_sb, jbegin_count) ;
+ reiserfs_update_inode_transaction(inode) ;
windex = push_journal_writer("delete_inode") ;
reiserfs_delete_object (, inode);
@@ -232,6 +233,7 @@
reiserfs_update_sd(th, inode) ;
journal_end(th, s, len) ;
journal_begin(th, s, len) ;
+ reiserfs_update_inode_transaction(inode) ;
}
// it is called by get_block when create == 0. Returns block number
@@ -567,6 +569,7 @@
TYPE_ANY, 3/*key length*/);
if ((new_offset + inode->i_sb->s_blocksize) >= inode->i_size) {
journal_begin(, inode->i_sb, jbegin_count) ;
+ reiserfs_update_inode_transaction(inode) ;
transaction_started = 1 ;
}
research:
@@ -591,6 +594,7 @@
if (!transaction_started) {
pathrelse() ;
journal_begin(, inode->i_sb, jbegin_count) ;
+ reiserfs_update_inode_transaction(inode) ;
transaction_started = 1 ;
goto research ;
}
@@ -658,6 +662,7 @@
*/
pathrelse() ;
journal_begin(, inode->i_sb, jbegin_count) ;
+ reiserfs_update_inode_transaction(inode) ;
transaction_started = 1 ;
goto research;
}
@@ -1277,6 +1282,10 @@
return ;
}
lock_kernel() ;
+
+/* this is really only used for atime updates, so they don't have
+** to be included in O_SYNC or fsync
+*/
journal_begin(, inode->i_sb, 1) ;
reiserfs_update_sd (, inode);
journal_end(, inode->i_sb, 1) ;
@@ -1650,6 +1659,7 @@
** (it will unmap bh if it packs).
*/
journal_begin(, p_s_inode->i_sb, JOURNAL_PER_BALANCE_CNT * 2 ) ;
+reiserfs_update_inode_transaction(p_s_inode) ;
windex = push_journal_writer("reiserfs_vfs_truncate_file") ;
reiserfs_do_truncate (, p_s_inode, page, update_timestamps) ;
pop_journal_writer(windex) ;
@@ -1696,6 +1706,7 @@
start_over:
lock_kernel() ;
journal_begin(, inode->i_sb, jbegin_count) ;
+reiserfs_update_inode_transaction(inode) ;
make_cpu_key(, inode, byte_offset, TYPE_ANY, 3) ;
@@ -1927,22 +1938,34 @@
static int reiserfs_commit_write(struct file *f, struct page *page,
[PATCH] speedup reiserfs O_SYNC and fsync
Hello everyone,
This patch makes reiserfs O_SYNC and fsync faster by only
committing the last transcation a file/dir was included in,
instead of forcing a commit on the current transaction.
More speedups are still possible, this patch is fairly conservative.
It is based on 2.4.7-pre6 + the direct-indirect target flushing
patch I just sent. More testers would be greatly appreciated ;-)
Note, this changes the reiserfs in-core inode. modules users need
to recompile the whole kernel.
-chris
diff -Nru a/fs/reiserfs/dir.c b/fs/reiserfs/dir.c
--- a/fs/reiserfs/dir.c Thu Jul 12 10:46:26 2001
+++ b/fs/reiserfs/dir.c Thu Jul 12 10:46:26 2001
@@ -47,22 +47,10 @@
};
int reiserfs_dir_fsync(struct file *filp, struct dentry *dentry, int datasync) {
- int ret = 0 ;
- int windex ;
- struct reiserfs_transaction_handle th ;
-
lock_kernel();
-
- journal_begin(th, dentry-d_inode-i_sb, 1) ;
- windex = push_journal_writer(dir_fsync) ;
- reiserfs_prepare_for_journal(th.t_super, SB_BUFFER_WITH_SB(th.t_super), 1) ;
- journal_mark_dirty(th, dentry-d_inode-i_sb, SB_BUFFER_WITH_SB
(dentry-d_inode-i_sb)) ;
- pop_journal_writer(windex) ;
- journal_end_sync(th, dentry-d_inode-i_sb, 1) ;
-
- unlock_kernel();
-
- return ret ;
+ reiserfs_commit_for_inode(dentry-d_inode) ;
+ unlock_kernel() ;
+ return 0 ;
}
diff -Nru a/fs/reiserfs/file.c b/fs/reiserfs/file.c
--- a/fs/reiserfs/file.cThu Jul 12 10:46:26 2001
+++ b/fs/reiserfs/file.cThu Jul 12 10:46:26 2001
@@ -50,6 +50,7 @@
lock_kernel() ;
down (inode-i_sem);
journal_begin(th, inode-i_sb, JOURNAL_PER_BALANCE_CNT * 3) ;
+reiserfs_update_inode_transaction(inode) ;
#ifdef REISERFS_PREALLOCATE
reiserfs_discard_prealloc (th, inode);
@@ -83,10 +84,7 @@
int datasync
) {
struct inode * p_s_inode = p_s_dentry-d_inode;
- struct reiserfs_transaction_handle th ;
int n_err = 0;
- int windex ;
- int jbegin_count = 1 ;
lock_kernel() ;
@@ -94,14 +92,9 @@
BUG ();
n_err = fsync_inode_buffers(p_s_inode) ;
- /* commit the current transaction to flush any metadata
- ** changes. sys_fsync takes care of flushing the dirty pages for us
- */
- journal_begin(th, p_s_inode-i_sb, jbegin_count) ;
- windex = push_journal_writer(sync_file) ;
- reiserfs_update_sd(th, p_s_inode);
- pop_journal_writer(windex) ;
- journal_end_sync(th, p_s_inode-i_sb,jbegin_count) ;
+
+ reiserfs_commit_for_inode(p_s_inode) ;
+
unlock_kernel() ;
return ( n_err 0 ) ? -EIO : 0;
}
diff -Nru a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
--- a/fs/reiserfs/inode.c Thu Jul 12 10:46:26 2001
+++ b/fs/reiserfs/inode.c Thu Jul 12 10:46:26 2001
@@ -41,6 +41,7 @@
down (inode-i_sem);
journal_begin(th, inode-i_sb, jbegin_count) ;
+ reiserfs_update_inode_transaction(inode) ;
windex = push_journal_writer(delete_inode) ;
reiserfs_delete_object (th, inode);
@@ -232,6 +233,7 @@
reiserfs_update_sd(th, inode) ;
journal_end(th, s, len) ;
journal_begin(th, s, len) ;
+ reiserfs_update_inode_transaction(inode) ;
}
// it is called by get_block when create == 0. Returns block number
@@ -567,6 +569,7 @@
TYPE_ANY, 3/*key length*/);
if ((new_offset + inode-i_sb-s_blocksize) = inode-i_size) {
journal_begin(th, inode-i_sb, jbegin_count) ;
+ reiserfs_update_inode_transaction(inode) ;
transaction_started = 1 ;
}
research:
@@ -591,6 +594,7 @@
if (!transaction_started) {
pathrelse(path) ;
journal_begin(th, inode-i_sb, jbegin_count) ;
+ reiserfs_update_inode_transaction(inode) ;
transaction_started = 1 ;
goto research ;
}
@@ -658,6 +662,7 @@
*/
pathrelse(path) ;
journal_begin(th, inode-i_sb, jbegin_count) ;
+ reiserfs_update_inode_transaction(inode) ;
transaction_started = 1 ;
goto research;
}
@@ -1277,6 +1282,10 @@
return ;
}
lock_kernel() ;
+
+/* this is really only used for atime updates, so they don't have
+** to be included in O_SYNC or fsync
+*/
journal_begin(th, inode-i_sb, 1) ;
reiserfs_update_sd (th, inode);
journal_end(th, inode-i_sb, 1) ;
@@ -1650,6 +1659,7 @@
** (it will unmap bh if it packs).
*/
journal_begin(th, p_s_inode-i_sb, JOURNAL_PER_BALANCE_CNT * 2 ) ;
+reiserfs_update_inode_transaction(p_s_inode) ;
windex = push_journal_writer(reiserfs_vfs_truncate_file) ;
reiserfs_do_truncate (th, p_s_inode, page, update_timestamps) ;
pop_journal_writer(windex) ;
@@ -1696,6 +1706,7 @@
start_over:
lock_kernel() ;
journal_begin(th, inode-i_sb, jbegin_count) ;
+reiserfs_update_inode_transaction(inode) ;
make_cpu_key(key, inode, byte_offset, TYPE_ANY, 3) ;
@@ -1927,22 +1938,34 @@
static int reiserfs_commit_write(struct file *f, struct page *page,
Re: Security hooks, standard linux security embedded use
Hi Linda, This seems very much in line with what Reiser4 is doing for DARPA, and what SE Linux is doing for the NSA. Or at least what Linus told the SE Linux folks he would like them to write.:-) I am quite supportive of what you advocate generally, and I look forward to cooperating with you in the details. May I suggest we contact the SE Linux folks, and each of our teams establish a point-of-contact to work on developing the details of what needs to be done? We call your security hooks security plugins or secplugs in Reiser4, mostly to identify that they are a component of the Reiser4 plugin approach to extensibility. Reiser4 is getting underway this month. We are willing to adapt our terminology and coding to be be consistent with yours. We don't really have a need to be the leaders in this area. We just need to get the job done, and to ensure that nothing that is done crimps our ability to accomplish our objectives. Our project objectives are somewhat describable as make it easy for folks like the NSA and the DoD to add new security features to Reiser4 by building the infrastructure for them. We will ship one implementation on top of that infrastructure that will implement ACLs, but we are more interested in enabling others than in doing ourselves. If the NSA or SGI wants to lead us a bit on this, that is fine with us. Our main insistence is going to be that the hooks should be very general, but I suspect you and the NSA also want that. We also need to have coding completed in ~8 months, so that it can all be debugged and stable and sent to Linus by Sep. 30th of next year. Do you have a list of all the hooks, etc., yet? Do you have anything like a general architecture for, given some vfs operation, and given some pluginid indicating object type, and given some secplugid (e.g. it might be the id of a secplug implementing an ACL), have the plugin check that the operation is allowable by calling the secplug (security hook) indicated by the secplugid? I think what is needed is an MxN matrix of security checks, where M is the number of vfs operations, and N is the number of secplugs. I am open to the idea that it should be MxNxO, where O is the number of security policies, though I don't plan to personally implement more than one security policy to ship with Reiser4 by default because I am pretty lazy. It won't surprise me if I end up shipping only one secplug with reiser4 initially (probably one implementing something embodying NT ACLs and unix permissions), and leave it to others to add the rest of them). I am quite supportive of your notion that some users have no need at all for security, and that they should be allowed a lightweight solution for their needs, though I will leave it to them to write that on top of the infrastructure I/we give them.:-) I envision the VFS operation invoking the plugin which invokes the secplug whose implementation varies with the choice of security policy compiled in. I don't honestly see the real usage critical need for dynamic loading of security policy modules, but I can yield on this if you see the need and code it since it probably isn't complex to code. I do like the idea of all of the code implementing a given security policy being isolated into its own single file/directory. Do you have any ideas on how to export to user space the ability to query what the permissions are, given that the permissions are being abstracted like this? I got your email, but I wasn't on the to: or cc: list. This confused me, so I invented a to: list that should reach all those likely to be interested in this. I am guessing this will be okay with you. Best, Hans LA Walsh wrote: Dear Linus et al., Sorry for the 'form' letter instead of individual names, but I didn't want to have to send this out separately to every kernel developer I know on LKML. I am asking for your input on the concept of moving the standard Linux security checks into a Linux Security Module. Discussion has come up on the Linux Security Module list about whether or not the current linux security (file mode bits, uid checking, etc.) should be modularized in the development of an LSM framework implementation This would entail moving all of the standard checks out of the kernel into a standard security module that, by default, would be the security policy selected and compiled in during kernel configuration and build. This seems to us (@sgi) to be the best solution to allow a completely configurable security policy. This option allows a policy creator complete flexibility in how or whether or not existing security is called. For example, in POSIX 1e style Mandatory Access Control, the information in the inode is also part of the protected object. So if a process doesn't have access under MAC, the DAC checks wouldn't even be executed since it doesn't have access to the permission
Re: Security hooks, standard linux security embedded use
On Thu, Jul 12, 2001 at 09:35:20PM +0400, Hans Reiser wrote: Hi Linda, This seems very much in line with what Reiser4 is doing for DARPA, and what SE Linux is doing for the NSA. Or at least what Linus told the SE Linux folks he would like them to write.:-) I am quite supportive of what you advocate generally, and I look forward to cooperating with you in the details. The details can be currently found in the most recent patch against 2.4.6 at: http://lsm.immunix.org/patches/lsm-2001_07_06-2.4.6.patch.gz There's a bit more information available, including the latest version of the patch at all times, available as a bitkeeper repository at: http://lsm.immunix.org/ thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
