[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
On Thursday, November 02, 2006 10:03:25 PM -0600 Mike Gerdts wrote: > However, sync(1m) could > do the same check that sync(2) does and return the appropriate error. Ugh! No, thank you. I already see enough trouble with programs that think they "know" what the privilege model is and refuse to run if, say, the UID is not 0, or the mode on some file is not what that (ACL-unaware) program expects, or whatever. As a filesystem developer, I've seen the same problem with OS's whose VFS layer decides that the user won't be able to change some property of a file because his uid is not the same as the file's, and returns an error without ever bothering to pass the operation to the filesystem. Guessing whether you are allowed to do something and then not bothering to try if the answer is "no" will always come back to bite you, or someone. > 4) Alter sync(1m) to check for PRIV_SYS_SYNC and say "Permission > Denied" and exit with a non-zero value if the permission is not held. No. If you print "Permission Denied", it better be because some syscall return EPERM. Don't fake it. IMHO, it's better for sync(1m) to silently do nothing than to print a bogus error message for an operation it never tried. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
>> Assuming we do steps 1 and 2 above, do we get into any problems with >> POSIX compliance if the default basic privilege set does not include >> PRIV_SYS_SYNC? There is no such thing as a "default basic set". There's a "basic set" and there's the "default set" users get when they login; they are generally the same but need not be. An administrator CANNOT manipulate the basic set; he can manipulate the default. Making sync() privileged would violate POSIX; but with basic privileges that is not an issue because everyone gets them in the default configuration. Casper
[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
Mike Gerdts wrote: > On 10/30/06, Darren J Moffat wrote: >> James Carlson wrote: >> Why, other than the returning an error we already have 5 such privileges >> in the basic set. Now in each of those cases (proc_info, proc_session, >> proc_fork, proc_exec, file_link_any) there is a way to return an error >> for sync(2) but there is for 'lockfs -f'. > > I assume the above was supposed to be "there is no way to return an > error for sync(2)..." Yes I did. > It seems as though the key interest in non-root users being able to > run sync(1m) is in reaction to some perceived doom on its way (thunder > that comes a few seconds after the lightning, etc.). If sync(2) were > change to check for a privilege (PRIV_SYS_SYNC?) before calling vfs > sync(), it indeed would not return an error. However, sync(1m) could > do the same check that sync(2) does and return the appropriate error. What check ? Only the kernel (and the Xserver when TX is running) checks privileges, applications should never check privileges and make assumptions based on them. > 'lockfs -f' seems as though it would be able to get an error from > ufs_fioffs(). Yes or from the equivalent for other filesystems that implement that ioctl as well. > Does it make sense to progress with this as: > > 1) Create a new privilege PRIV_SYS_SYNC Seems as reasonable a name as any. > 2) Alter sync(2) or vfs_sync() to only perform the sync if the calling > process has PRIV_SYS_SYNC. Either is probably fine. > 3) Alter ufs_fioffs() to only perform the sync if the calling process > has PRIV_SYS_SYNC. On failure return EPERM. Yes and check ZFS and the other filesystems too. > 4) Alter sync(1m) to check for PRIV_SYS_SYNC and say "Permission > Denied" and exit with a non-zero value if the permission is not held. No applications should not check privileges, though in this case it might be okay since you know you need sys_sync to call sync(2) and if you don't have it what is the point. In the general case though one is supposed to try the operation rather than assume based on the privileges one has. > 5) Alter rc0.sh to only call sync(1M) if running in the global zone. > 6) Alter svc.startd(1M) to only call sync(2) if running in the global zone. I'll leave those to a zones expert to answer. > Assuming we do steps 1 and 2 above, do we get into any problems with > POSIX compliance if the default basic privilege set does not include > PRIV_SYS_SYNC? As soon as you manipulate the privilege sets you are already operating outside of POSIX so it doesn't apply. -- Darren J Moffat
[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
On Fri 03 Nov 2006 at 10:34AM, Casper.Dik at sun.com wrote: > > >> Assuming we do steps 1 and 2 above, do we get into any problems with > >> POSIX compliance if the default basic privilege set does not include > >> PRIV_SYS_SYNC? > > There is no such thing as a "default basic set". > > There's a "basic set" and there's the "default set" users get when > they login; they are generally the same but need not be. > > An administrator CANNOT manipulate the basic set; he can manipulate > the default. > > Making sync() privileged would violate POSIX; but with basic privileges > that is not an issue because everyone gets them in the default > configuration. What SUSv3 seems to say is that I/Os must be scheduled before the sync completes, but the I/Os need not occur prior to the sync(2) call returning. It also says nothing about what might happen if not all of the I/Os complete, or whether the system can be shut down without all I/Os completing. So one wonders whether (in the event an unprivileged user issues a sync) you could just "schedule" the I/O to happen say, 1000 years in the future. The poorly defined spec from POSIX seems to be in conflict with how much effort we might go to in order to comply with it... Maybe there's a more detailed standards definition somewhere I've not seen? -dp -- Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp
[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
On 10/30/06, Darren J Moffat wrote: > James Carlson wrote: > Why, other than the returning an error we already have 5 such privileges > in the basic set. Now in each of those cases (proc_info, proc_session, > proc_fork, proc_exec, file_link_any) there is a way to return an error > for sync(2) but there is for 'lockfs -f'. I assume the above was supposed to be "there is no way to return an error for sync(2)..." It seems as though the key interest in non-root users being able to run sync(1m) is in reaction to some perceived doom on its way (thunder that comes a few seconds after the lightning, etc.). If sync(2) were change to check for a privilege (PRIV_SYS_SYNC?) before calling vfs sync(), it indeed would not return an error. However, sync(1m) could do the same check that sync(2) does and return the appropriate error. 'lockfs -f' seems as though it would be able to get an error from ufs_fioffs(). > > For the zones case maybe it can not be in the default set of privileges > given to a zone, so by default they get to run more quickly. Just like > with many other privileges the admin can choose the limitset of > privileges the zone has. True enough. Does it make sense to progress with this as: 1) Create a new privilege PRIV_SYS_SYNC 2) Alter sync(2) or vfs_sync() to only perform the sync if the calling process has PRIV_SYS_SYNC. 3) Alter ufs_fioffs() to only perform the sync if the calling process has PRIV_SYS_SYNC. On failure return EPERM. 4) Alter sync(1m) to check for PRIV_SYS_SYNC and say "Permission Denied" and exit with a non-zero value if the permission is not held. 5) Alter rc0.sh to only call sync(1M) if running in the global zone. 6) Alter svc.startd(1M) to only call sync(2) if running in the global zone. Assuming we do steps 1 and 2 above, do we get into any problems with POSIX compliance if the default basic privilege set does not include PRIV_SYS_SYNC? Mike -- Mike Gerdts http://mgerdts.blogspot.com/
[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
>Why, other than the returning an error we already have 5 such privileges >in the basic set. Now in each of those cases (proc_info, proc_session, >proc_fork, proc_exec, file_link_any) there is a way to return an error >for sync(2) but there is for 'lockfs -f'. And it's exactly what the basic set is intended for. Casper
[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
James Carlson wrote: > Darren J Moffat writes: >> Dan Price wrote: >>> I know that at some point the performance guys wanted to make sync's by >>> non-root users do nothing, but IIRC it was deemed too risky or something. >>> Maybe we should go do that for Nevada. Anyone in request-sponsor land >>> have some background info they could point us at? > [...] >> I think these might be ideally specified as basic privileges, that is >> all users have them by default (just like the ability to see the >> existence of others processes in ps output) but they can be removed by >> the system admin. > > I think it'd be a little odd to have a privilege that works like > this. The implication seems to be that if you have the privilege, > then sync does what it's always done. If you don't, then sync > silently does nothing at all. (I don't see any clear way for sync(2) > to return a failure ...) Why, other than the returning an error we already have 5 such privileges in the basic set. Now in each of those cases (proc_info, proc_session, proc_fork, proc_exec, file_link_any) there is a way to return an error for sync(2) but there is for 'lockfs -f'. > For zones, why would I want to choose between allowing zones to > operate more quickly (by removing this privilege) and allowing zone > users to save their work during thunderstorms? I'm not sure I know > how a customer should make such a decision. For the zones case maybe it can not be in the default set of privileges given to a zone, so by default they get to run more quickly. Just like with many other privileges the admin can choose the limitset of privileges the zone has. -- Darren J Moffat
sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
Dan Price wrote: > I know that at some point the performance guys wanted to make sync's by > non-root users do nothing, but IIRC it was deemed too risky or something. > Maybe we should go do that for Nevada. Anyone in request-sponsor land > have some background info they could point us at? For want of a better place to discuss this I'm directing this to security discuss. Personally I depend on the fact that I can sync as a non root user. I might be paranoid or being silly but any time I hear thunderclaps I type sync. I also do it to when my laptop battery is getting low. If you were to modify sync you would also need to modify lockfs so that lockfs -f doesn't work without privilege either. I think these might be ideally specified as basic privileges, that is all users have them by default (just like the ability to see the existence of others processes in ps output) but they can be removed by the system admin. -- Darren J Moffat
[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
Darren J Moffat writes: > Dan Price wrote: > > I know that at some point the performance guys wanted to make sync's by > > non-root users do nothing, but IIRC it was deemed too risky or something. > > Maybe we should go do that for Nevada. Anyone in request-sponsor land > > have some background info they could point us at? [...] > I think these might be ideally specified as basic privileges, that is > all users have them by default (just like the ability to see the > existence of others processes in ps output) but they can be removed by > the system admin. I think it'd be a little odd to have a privilege that works like this. The implication seems to be that if you have the privilege, then sync does what it's always done. If you don't, then sync silently does nothing at all. (I don't see any clear way for sync(2) to return a failure ...) For zones, why would I want to choose between allowing zones to operate more quickly (by removing this privilege) and allowing zone users to save their work during thunderstorms? I'm not sure I know how a customer should make such a decision. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
On Mon, Oct 30, 2006 at 04:14:33PM +0100, Casper.Dik at Sun.COM wrote: > >Why, other than the returning an error we already have 5 such privileges > >in the basic set. Now in each of those cases (proc_info, proc_session, > >proc_fork, proc_exec, file_link_any) there is a way to return an error > >for sync(2) but there is for 'lockfs -f'. > > And it's exactly what the basic set is intended for. What's the problem here? That on a large SunRay server the likelihood of users running 'sync' at any given time is very high, and that this affects performance? Or is it that one user can hog I/O resources? If the former, then make sync/lockfs -f take their time; make it a resource control, set the minimum for mere mortal users to five seconds (think ZFS :) and declare victory. If the latter, then perhaps we need better per-user I/O resource controls. Nico --
