No subject
Tue Apr 27 07:05:54 EDT 2010
language and it never modifes the behaviour of software. It just
prohibits the assignment (or modification) to a variable which is
expected not to be modified.
In other word, it is a feature for programmers and doesn't enhance the
security level. Actually programmers can bypass 'const' easily by
indirect assignment.
Also the grsec/pax patches modifies some assignments to the member
of struct brabra_operation in mainline kernel, but they don't make the
confirmation fot that. For example, they replaced these assignments by
declaring a structure statically.
(I know they don't make member of file_operations 'const', so this is
exmaple is unrelated to the above.)
- /* inherit and extend fuse_dev_operations */
- cuse_channel_fops = fuse_dev_operations;
- cuse_channel_fops.owner = THIS_MODULE;
- cuse_channel_fops.open = cuse_channel_open;
- cuse_channel_fops.release = cuse_channel_release;
+static const struct file_operations cuse_channel_fops = {
+ .owner = THIS_MODULE,
+ .llseek = no_llseek,
+ .read = do_sync_read,
+ .aio_read = fuse_dev_read,
+ .write = do_sync_write,
+ .aio_write = fuse_dev_write,
+ .poll = fuse_dev_poll,
+ .open = cuse_channel_open,
+ .release = cuse_channel_release,
+ .fasync = fuse_dev_fasync,
+};
By this modification, there exists major possible future problem I am
afraid. _If_ fuse_dev_operations is modified, then this code needs to
follow the change. But it is hard to detect such modification since
there is no trick to do so. Generally it is recommended to put code such
like this.
----------------------------------------------------------------------
int n;
#define MakeSure(super, derive, member) do {
n++;
BUG_ON(super.member != derive.member);
} while (0);
n++; /* owner */
MakeSure(fuse_dev_operations, cuse_channel_fops, llseek);
MakeSure(fuse_dev_operations, cuse_channel_fops, read);
:::
BUG_ON(n != sizeof(cuse_channel_fops)/sizeof(cuse_channel_fops.owner));
----------------------------------------------------------------------
This piece of code ensures two things.
- cuse_channel_fops correctly inherits fuse_dev_operations, eg. all
members are equivalent except the overrided ones.
- if some members are added or deleted from struct file_operations, it
should be detected by a debugging feature, the variable 'n'.
Without such trick, I am afraid the simple modification is a regression.
More information about the grsecurity
mailing list