Re: KAUTH_PROCESS_SCHEDULER_*AFFINITY restricted to root in default secmodel?
On Mon, 29 Aug 2011 01:07:52 +0200 Alistair Crooks wrote: Sorry for replying to an old thread, I'm still catching up with mail :) > > i've found this some what annoying. IMO, we should have a a way to say > > "let normal users do this". i'm not sure sysctl is the right place, but > > maybe an overlay secmodel? on some of my machines, i don't want to have > > to be root to do this. it's annoying to have to use root to get the > > highest performance i can out of an application. > > > > the current default is fine, however. > > Something analogous to our friends: > > % sysctl -a | grep mount > vfs.generic.usermount = 0 > security.models.suser.usermount = 0 > % And/or like security.models.bsd44.curtain, etc; I think that a sysctl for this would be nice too. Also, I'm not sure if this is doable (an annoyance if users and scripts have been using the old knobs), but I tend to think that sysctls that affect the default secmodel (bsd44) should ideally all be under security.models.bsd44.? -- Matt
Re: KAUTH_PROCESS_SCHEDULER_*AFFINITY restricted to root in default secmodel?
On Mon, Aug 29, 2011 at 08:44:39AM +1000, matthew green wrote: > > > I've just had my first occasion to play with the processor affinity > > code, via porting some code from linux. It was very straightforward, > > but there's one glaring difference: linux doesn't (by default, anyway) > > require root to use their sched_setaffinity(), while we do require root > > (by default) for pthread_setaffinity_np(). > > > > I don't pretend to understand the security ramifications regarding > > processor affinity; I do wonder, however, whether it warrants requiring > > elevated privilege (and possible exposure via other code in the process > > which doesn't require root for normal operation) to prevent allowing > > users to pin their own code to a particular cpu by default. Are we sure > > we've made the right (default) tradeoff here? > > > > For my own use, I know I can tweak the secmodel to permit > > KAUTH_PROCESS_SCHEDULER_SETAFFINITY . (and now I'm going to research > > how to actually do it. :) > > i've found this some what annoying. IMO, we should have a a way to say > "let normal users do this". i'm not sure sysctl is the right place, but > maybe an overlay secmodel? on some of my machines, i don't want to have > to be root to do this. it's annoying to have to use root to get the > highest performance i can out of an application. > > the current default is fine, however. Something analogous to our friends: % sysctl -a | grep mount vfs.generic.usermount = 0 security.models.suser.usermount = 0 % perhaps? Regards, Alistair
re: KAUTH_PROCESS_SCHEDULER_*AFFINITY restricted to root in default secmodel?
> I've just had my first occasion to play with the processor affinity > code, via porting some code from linux. It was very straightforward, > but there's one glaring difference: linux doesn't (by default, anyway) > require root to use their sched_setaffinity(), while we do require root > (by default) for pthread_setaffinity_np(). > > I don't pretend to understand the security ramifications regarding > processor affinity; I do wonder, however, whether it warrants requiring > elevated privilege (and possible exposure via other code in the process > which doesn't require root for normal operation) to prevent allowing > users to pin their own code to a particular cpu by default. Are we sure > we've made the right (default) tradeoff here? > > For my own use, I know I can tweak the secmodel to permit > KAUTH_PROCESS_SCHEDULER_SETAFFINITY . (and now I'm going to research > how to actually do it. :) i've found this some what annoying. IMO, we should have a a way to say "let normal users do this". i'm not sure sysctl is the right place, but maybe an overlay secmodel? on some of my machines, i don't want to have to be root to do this. it's annoying to have to use root to get the highest performance i can out of an application. the current default is fine, however. .mrg.
Re: KAUTH_PROCESS_SCHEDULER_*AFFINITY restricted to root in default secmodel?
On 28.08.2011 22:03, Jeff Rizzo wrote: > I've just had my first occasion to play with the processor affinity > code, via porting some code from linux. It was very straightforward, > but there's one glaring difference: linux doesn't (by default, anyway) > require root to use their sched_setaffinity(), while we do require root > (by default) for pthread_setaffinity_np(). > > I don't pretend to understand the security ramifications regarding > processor affinity; I do wonder, however, whether it warrants requiring > elevated privilege (and possible exposure via other code in the process > which doesn't require root for normal operation) to prevent allowing > users to pin their own code to a particular cpu by default. Are we sure > we've made the right (default) tradeoff here? I think so. In a more broad thinking about resources, letting consumers have some form of control on producers is always problematic. At least when you have to deal with availability (which is a security concern BTW). For that particular case, if you want a specific example of why this can be problematic, have a look at an article written by Colin (Percival) a while back [1]. It's a proof of concept regarding a side channel that could be used to obtain information about another process when both are executing in a specific context (shared caches, like for hyperthreading in his article). Giving a LWP the right to pin to a certain CPU here is very bad: for example, with adequate time measurements you can obtain private RSA keys when used for calculation. [1] http://www.daemonology.net/papers/htt.pdf -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: KAUTH_PROCESS_SCHEDULER_*AFFINITY restricted to root in default secmodel?
On Sun, Aug 28, 2011 at 01:03:14PM -0700, Jeff Rizzo wrote: > > I don't pretend to understand the security ramifications regarding > processor affinity; I do wonder, however, whether it warrants > requiring elevated privilege (and possible exposure via other code > in the process which doesn't require root for normal operation) to > prevent allowing users to pin their own code to a particular cpu by > default. Are we sure we've made the right (default) tradeoff here? I am pretty sure. It makes resource consumption attacks easier and it is not hard to see how to use it to make timing attacks against cryptographic code in other processes _much_ easier.
KAUTH_PROCESS_SCHEDULER_*AFFINITY restricted to root in default secmodel?
I've just had my first occasion to play with the processor affinity code, via porting some code from linux. It was very straightforward, but there's one glaring difference: linux doesn't (by default, anyway) require root to use their sched_setaffinity(), while we do require root (by default) for pthread_setaffinity_np(). I don't pretend to understand the security ramifications regarding processor affinity; I do wonder, however, whether it warrants requiring elevated privilege (and possible exposure via other code in the process which doesn't require root for normal operation) to prevent allowing users to pin their own code to a particular cpu by default. Are we sure we've made the right (default) tradeoff here? For my own use, I know I can tweak the secmodel to permit KAUTH_PROCESS_SCHEDULER_SETAFFINITY . (and now I'm going to research how to actually do it. :) Thanks, +j
