Re: Call for a hacker.... security.bsd.see_other_uids in jails only

В Птн, 21.05.2004, в 12:41, Pawel Jakub Dawidek пишет:
> On Fri, May 21, 2004 at 12:02:17PM +0300, Ruslan Ermilov wrote:
> +> I like the idea of per-jail sysctl MIB trees, e.g.:
> +> 
> +> jail.<JID>.security.bsd
> +> 
> +> When jail gets created, the generic sysctl code would traverse
> +> the primary sysctl tree (excluding the jail. subtree), and copy
> +> and attach those that have some jail-related flag to the
> +> jail.<JID>. branch.
> +> 
> +> Inside the jail, jail.<JID>.security.bsd branch would map to
> +> just security.bsd.
> +> 
> +> The generic sysctl code, when it detects it's run within a
> +> jail, will find a sysctl node "foo.bar", and if it has a
> +> jail-clone flag set, will remap a query to jail.<JID>.foo.bar.
> +> 
> +> Whether it's allowed to change a particular sysctl inside
> +> a jail is another matter.
> 
> There are two main issues with our current sysctls implementation:
> 1. We cannot hide sysctls/sysctl-trees.
> 2. We're operating in most cases on integers.
> 
> We can work on 1, but we can't hack 2 easly, we have to transform
> sysctls, that have to be treated on per-jail basics from SYSCTL_INT
> to SYSCTL_PROC and if so, I'm not sure what for do we need
> security.jail.<JID> trees then. We can implement them in the same
> way security.jail.jailed is impelemented (it shows different value
> outside a jail and different inside) and if we want to change it:
> 
> 	# jexec <JID> /sbin/sysctl <some_sysctl>=<some_value>
> 
> Of course, there could be no /sbin/sysctl utility inside a jail,
> but I'll still suggest to add '-j' option to sysctl command to
> work just like 'killall -j' (i.e. jail_attach(<JID>); sysctl();).
killall -j = bad idea..
It not kill fork bomb started inside jail.
for protect from this situations me must have jail command for stop jail
and kill all tasks inside.

-- 
Alex Lyashkov <shadow_at_psoft.net>
PSoft