owl-dev - features to port #2

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 8 Aug 2012 18:57:20 +0400
From: Vasily Kulikov <segoon@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: features to port #2

Solar,

I'm "unrolling" the TODO list I've previously posted here.


1) SYSFS_RESTRICT

I think we need this userspace interface:

 a) CONFIG_FS_SYSFS_PERMISSION_MODE_{ROOT,GROUP,ALL} (defaults to GROUP in
    Owl).  Makes umask 0077, 0027, 0022.
 b) CONFIG_FS_SYSFS_PERMISSION_GROUP_ID = some new gid for _sysfs group.
 c) kernel parameters sysfs_permission_mode=root/group/all and
    sysfs_permission_group_id=xxx to override (a) and (b).
 d) /proc/sys/fs/sysfs_{permission_mode,permission_group_id} to override (a)
    and (b) at runtime.

The only problem is that sysfs' policy should be configurable per-CT.
It means that before CT's init process (with pid=1) is created both settings
must be already configured.  That's a problem as initial sysfs files are
created on VZCTL_ENV_CREATE_DATA before CT's init is spawned.

So, we should be able to pass this policy info at the ENV_CREATE stage.  vzctl
passes some data as ENV_CREATE ioctl's argument.  This data is a struct:

struct env_create_param3 {
	__u64 iptables_mask;
	__u64 feature_mask;
	__u32 total_vcpus;
	__u32 pad;
	__u64 known_features;
};

We should be able to pass 2 data blocks: gid and umask.  The best way I could
think about is: use pad as gid field and reuse 3 flag bits in known_features:

whether we use pad as gid
2 bits for 3-state umask

This allows us to 1) still use old vzctl which doesn't know anything about
this sysfs stuff and 2) not conflict with possible future upgrades of
struct env_creat_paramX -- I suppose it will add some new fields after
known_features.


2) log spoofing protection

As was discussed at k-h@, the trivial filter-everything-on-printk doesn't
work.  Linus suggested to filter them at %s level, which obviously touches
non-printk code.  I didn't investigate whether there are problems with it.
Some fixes to drivers still might be needed.


3) PAX_REFCOUNT

As already discussed, patching refcounting at atomic_t level is annoying
(there are MANY users of it as a refcount).  I'd want to port a smaller
version of it by patching only kref code, not atomic_t code.  Yes, it will not
fix all these plenty atomic_t users, but we will not get many false positives
too.  Moving fitting atomic_t users to kref is a sort of wasting of time for
now.

So, I'd want to implement it for kref only as a configure option (as it might
slow down some very hot paths on 0,0..0% :-))


4) PAX_USERCOPY

I have no additions to the previous version of upstream patch.  It should be
cleaned, moved to #ifdef CONFIG_STRICT_USERCOPY_CHECKS, etc.   The only
question is about what to do on bad access.  I'd say it should be configurable
as /proc/sys/kernel/usercopy_overflow_action = 0 (nothing) / 1 (send SIG_KILL
and log) / 2 (panic).


Thanks,

-- 
Vasily
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.