Hi!
I'm looking around the LSM module and I know it has got some
functions for the filesystem part. Well, it looks good, but the
permission thing is not enough. In fact it's enough to check
the permission of an inode, but I'd like to check permissions
for a dentry AND its inode at the same place and time.
I don't know why the dentry can't be passed to the permission
function along with the inode in the VFS.
When a user opens a file it may be useful in some cases
to decide whether a user can access an inode for the
requested operation according to it's the dentry (and
to the parent dentry)
In this case you could specify rights for the directory
too affecting the files' permissions belonging to that dir.
like how Novell does.
Before it starts a flame: I don't say I would like to
have such a default feature in the kernel, but I'd like to
have the possibility to write a LSM.
In this case we could have some very interesting (useful
or not who knows) features. For example if there are two
hardlinks for an inode in two different directories, the user
could get different rights for the file depending on the
path he reaches it.
I've got some reports that people switching from Windows
(not mentioning those who would like to switch from Novell)
don not find the current file permission system satisfying
even with ACL.
I think there is a demand for an extended file access
feature. This could be done filesystem independent way
storing additional information in a database (at file level).
As I've been thinking for 2 days I think at least the
following modificatoins would be necessary:
int vfs_permission(struct inode *inode, int mask, struct dentry *dentry);
int permission(struct inode *inode, int mask, struct dentry *dentry);
and in the LSM the same.
The current permission checking method could be left
untouched and if there are some cases when the dentry
can be NULL it wouldn't hurt. But on the other hand
we could build something more complex in LSM if needed.
To be honest I'd welcome if the whole file permisssion
part were moved to LSM. It would allow us to override the
currently implemented default behavior easily.
Now the LSM is only an extension and if the vfs_permission
(or the i_ops->permission) fails then the security_ops->permission
can't override it.
If we also pass the "retval" to the LSM's permission
fn. then it can decide whether it wants to override the
previously failed perm. check or just returns the "retval".
We could get more control of these if the may_* functions
were moved to LSM as well.
Any thoughts about these?
Gabor
On Sat, Aug 31, 2002 at 06:16:04AM +0200, Gabor Kerenyi wrote:
>
> In this case we could have some very interesting (useful
> or not who knows) features. For example if there are two
> hardlinks for an inode in two different directories, the user
> could get different rights for the file depending on the
> path he reaches it.
I think you can already do this with the existing LSM interface, you can
always get the dentry for a given inode, right? I think there might be
a problem in determining the "real" path structure of the dentry all the
time due to mount locations, but that will be fixed up by the time 2.6
is out.
> To be honest I'd welcome if the whole file permisssion
> part were moved to LSM. It would allow us to override the
> currently implemented default behavior easily.
No! One of the main goals of the LSM design was to not override the
current Linux permission behavior. It can only deny access to things,
not be a permissive system of allowing access to things that the current
system denies. See the many threads on the LSM mailing list for the
reasons behind this.
thanks,
greg k-h
On Saturday 31 August 2002 07:21, Greg KH wrote:
> On Sat, Aug 31, 2002 at 06:16:04AM +0200, Gabor Kerenyi wrote:
> > In this case we could have some very interesting (useful
> > or not who knows) features. For example if there are two
> > hardlinks for an inode in two different directories, the user
> > could get different rights for the file depending on the
> > path he reaches it.
>
> I think you can already do this with the existing LSM interface, you can
> always get the dentry for a given inode, right?
How can I determine the dentry what the user actually acts on? Because
of hardlinks I thought it is impossible to find out the dentry having
only the inode. 1:n (inode:dentry) relation isn't it?
Or did I miss something?
> > To be honest I'd welcome if the whole file permisssion
> > part were moved to LSM. It would allow us to override the
> > currently implemented default behavior easily.
>
> No! One of the main goals of the LSM design was to not override the
> current Linux permission behavior. It can only deny access to things,
> not be a permissive system of allowing access to things that the current
> system denies. See the many threads on the LSM mailing list for the
> reasons behind this.
Well, the current LSM maybe designed this way. But as I see LSM
is modular. There is a capability.c in the security dir. It could still
deny access in the way I described, moreover the "security checks"
would be in the right place -> security/ (at least in my point of
view)
The capability.c is only _one_ module. It doesn't mean we can't have
more that work differently. User can choose among them.
(it would be great in the future if more sec. modules could be loaded
for a system - for instance one sec.modules deals with tasks, the
other deals with file permissions).
There are many situations where the current right management is
not good enough and with only having a "deny policy" they can't
be solved using LSM.
It would be up to the LSM to decide whether it wants to apply a "deny
policy" or an "allow policiy"
If we move all security checks from the VFS to the LSM then
the bahavior will be determined by the currently loaded LSM.
In your point of view:
the capability.c (or def_fileperm.c) can implement a deny policiy.
For the rest of the LSModules it's up to them.
Is it acceptable for you?
Having an "allow policiy" doesn't mean less security _if_ the loaded
LSM knows what it is doing. It can be as secure as a "deny policy"
if it is implemented in a proper way - it will always allow or deny
access exaclty how the root told to by setting permissions etc.
If the module is not implemented in a proper way then it means
a problem whether it denies or allows things.
OK. We can state that the current LSM design is restrictive and
only an extension to the current security checks. So it can't add
any extra security features (not checks) and therefore it's limitied
in its own way. With this interface nobody can customize the
system without hacking the very kernel (vfs for exmaple) to
achieve new behavior and features.
Or we can create another LSM say Core Linux Security Module
and its duty will be to move the security checks from the kernel
to a seperate place and call the LSM functions if needed.
You can't reprogram the security checks now. I know it's implemented
to be U*IX like. It's great, it's enough for me too. But why can't we
provide a possibility (only) to implement something else as well
instead of and/or in conjunction with the current one?
Would it be a big harm?
Thanks,
Gabor
On Fri, Aug 30, 2002 at 10:21:14PM -0700, Greg KH wrote:
> On Sat, Aug 31, 2002 at 06:16:04AM +0200, Gabor Kerenyi wrote:
> >
> > In this case we could have some very interesting (useful
> > or not who knows) features. For example if there are two
> > hardlinks for an inode in two different directories, the user
> > could get different rights for the file depending on the
> > path he reaches it.
>
> I think you can already do this with the existing LSM interface, you can
> always get the dentry for a given inode, right?
You get ALL dentries for the given inode. But I don't know,
whether such code traversion inode->i_dentry is valid in all situations.
Passing a dentry instead of inode is the easier variant, because
an dentry maps to exactly one inode, if it is a positive one[1]
The mapping from inode to dentries is 1:n and the thing the
poster wants is not possible with that, because the way the user
took to reach this inode is one of the n possibilities and we
don't know which one.
So this is a correctly pointed out design weakness: The way the
user took to reach the inode cannot be taken into account.
Regards
Ingo Oeser
[1] But we should never see permission checks for negative
dentries, since you cannot access what's not there ;-)
--
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
* Gabor Kerenyi ([email protected]) wrote:
> Hi!
>
> I'm looking around the LSM module and I know it has got some
> functions for the filesystem part. Well, it looks good, but the
> permission thing is not enough. In fact it's enough to check
> the permission of an inode, but I'd like to check permissions
> for a dentry AND its inode at the same place and time.
We are anticipating VFS changes that include passing a dentry/vfsmount
pair to the permission check. This gives you both the inode as well as
the point in the tree the user is accessing the inode.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
* Ingo Oeser ([email protected]) wrote:
>
> So this is a correctly pointed out design weakness: The way the
> user took to reach the inode cannot be taken into account.
Yes, this is known, and there are anticipated VFS changes to remedy
this.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
* Gabor Kerenyi ([email protected]) wrote:
>
> How can I determine the dentry what the user actually acts on? Because
> of hardlinks I thought it is impossible to find out the dentry having
> only the inode. 1:n (inode:dentry) relation isn't it?
> Or did I miss something?
You are correct. In addition you need the vfsmount to pin it to a
unique point in the namespace. As I mentioned, the dentry/vfsmount
pair is an anticipated change.
> If we move all security checks from the VFS to the LSM then
> the bahavior will be determined by the currently loaded LSM.
> In your point of view:
> the capability.c (or def_fileperm.c) can implement a deny policiy.
> For the rest of the LSModules it's up to them.
>
> Is it acceptable for you?
No, this does not sound like a safe transition. For starters we want a
fail safe mechanism.
> Having an "allow policiy" doesn't mean less security _if_ the loaded
> LSM knows what it is doing. It can be as secure as a "deny policy"
> if it is implemented in a proper way - it will always allow or deny
> access exaclty how the root told to by setting permissions etc.
> If the module is not implemented in a proper way then it means
> a problem whether it denies or allows things.
Indeed, however the invasive nature of a purely permissive policy along
with the ease of bugs is not a good way to begin merging a new project ;-)
Also, the capability interface provides a coarse grained permissive
interface, so all is not lost.
> OK. We can state that the current LSM design is restrictive and
> only an extension to the current security checks. So it can't add
> any extra security features (not checks) and therefore it's limitied
> in its own way. With this interface nobody can customize the
> system without hacking the very kernel (vfs for exmaple) to
> achieve new behavior and features.
Yes, this is intentional. Of course, depending on your notion of
security feature, it may already be supported or not fall into the
category of access controls, which LSM is providing.
> Or we can create another LSM say Core Linux Security Module
> and its duty will be to move the security checks from the kernel
> to a seperate place and call the LSM functions if needed.
> You can't reprogram the security checks now. I know it's implemented
> to be U*IX like. It's great, it's enough for me too. But why can't we
> provide a possibility (only) to implement something else as well
> instead of and/or in conjunction with the current one?
> Would it be a big harm?
Please review the LSM list archives as this has been discussed
extensively. The executive summary is that a restrictive design
provides simple assurance. A permissive design is both more invasive
and makes it easy to write dumb security bugs. The current focus is
merging the restrictive interface, later we can look at enhancements.
Basic walk before run philosophy ;-)
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Sunday 01 September 2002 02:26, Chris Wright wrote:
> * Ingo Oeser ([email protected]) wrote:
> >
> > So this is a correctly pointed out design weakness: The way the
> > user took to reach the inode cannot be taken into account.
>
> Yes, this is known, and there are anticipated VFS changes to remedy
> this.
Could you describe them, please?
--
Daniel
* Daniel Phillips ([email protected]) wrote:
> On Sunday 01 September 2002 02:26, Chris Wright wrote:
> > * Ingo Oeser ([email protected]) wrote:
> > >
> > > So this is a correctly pointed out design weakness: The way the
> > > user took to reach the inode cannot be taken into account.
> >
> > Yes, this is known, and there are anticipated VFS changes to remedy
> > this.
>
> Could you describe them, please?
For example, passing vfsmount/dentry pair to i_op->permission().
getattr() is already done, and last I heard I Al intends to do
setattr() as well.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Monday 02 September 2002 08:08, Chris Wright wrote:
> * Daniel Phillips ([email protected]) wrote:
> > On Sunday 01 September 2002 02:26, Chris Wright wrote:
> > > * Ingo Oeser ([email protected]) wrote:
> > > > So this is a correctly pointed out design weakness: The way the
> > > > user took to reach the inode cannot be taken into account.
> > >
> > > Yes, this is known, and there are anticipated VFS changes to remedy
> > > this.
> >
> > Could you describe them, please?
>
> For example, passing vfsmount/dentry pair to i_op->permission().
> getattr() is already done, and last I heard I Al intends to do
> setattr() as well.
Changing the i_op->permission() is the last step and the easiest, I think.
There will be more VFS changes. vfs_*, may_*, namei.c:permissoin,
path name lookup, LSM etc.
Moreover the i_op->permission() change will break the interface to
FileSystems but it could be easily fixed.
Gabor