Re: secure computing for 2.6.7

[Alexander Lyamin <flx@msu.ru>]

Tue, Aug 03, 2004 at 08:40:45AM -0400, Stephen Smalley wrote:
> On Wed, 2004-07-07 at 15:27, Hans Reiser wrote:
> > Am I right to think that this could complement nicely our plans 
> > described at www.namesys.com/blackbox_security.html
> Hi Hans,
> 
> Out of curiosity, what do you think that this proposal will achieve that
> cannot already be done via SELinux policy?  SELinux policy can already
> express access rules based not only on the executable and user, but even
> the entire call chain that led to a given executable.

convinience ? speed ?


RBAC is a Good Thing, but I wonder if it could provide throughout syntax analysis
for vfs related syscalls. As it is now.

At least what declared in their docs, fs-wise they are somewhat like this

Macro Name	Description
stat_file_perms	Permissions to call stat or access on a file.
x_file_perms	Permissions to execute a file.
r_file_perms	Permissions to read a file.
rx_file_perms	Permissions to read and execute a file.
rw_file_perms	Permissions to read and write a file.
ra_file_perms	Permissions to read and append to a file.
link_file_perms	Permissions to link, unlink, or rename a file.
create_file_perms	Permissions to create, access, and delete a file.
r_dir_perms	Permissions to read and search a directory.
rw_dir_perms	Permissions to read and modify a directory.
ra_dir_perms	Permissions to read and add entries to a directory.
create_dir_perms	Permissions to create, access, and delete a directory.
mount_fs_perms	Permissions to mount and unmount a filesystem.


*shrugs*
Well, I am probably wrong...

p.s. _AND_ if I remember correctly reiser4 supposed to provide finer-then-file grain security.
well, at least it easily could, being truly semantic-enabled fs.

-- 
"the liberation loophole will make it clear.."
lex lyamin