Re: syscall: sys_promote

[Coywolf Qi Hunt]

Bernd Petrovitsch wrote:

> On Mon, 2005-08-29 at 11:55 +0800, qiyong wrote:
>  
>
> > Erik Mouw wrote:
> >    
> >
> > > On Fri, Aug 26, 2005 at 05:25:37PM +0800, Coywolf Qi Hunt wrote:
> > >      
> > >
> > > > I just wrote a tool with kernel patch, which is to set the uid's of a running
> > > > process without FORK.
> > > >
> > > > The tool is at http://users.freeforge.net/~coywolf/pub/promote/
> > > > Usage: promote <pid> [uid]
> > > >
> > > > I once need such a tool to work together with my admin in order to tune my web
> > > > configuration.  I think it's quite convenient sometimes. 
> > > >
> > > > The situations I can image are:
> > > >
> > > > 1) root processes can be set to normal priorities, to serve web
> > > > service for eg.
> > > >        
> > > Most (if not all) web servers can be told to drop all privileges and
> > > run as a normal user. If not, you can use selinux to create a policy
> > > for such processes (IIRC that's what Fedora does).
> > >      
> > In this way, it's that the web servers themselves drop the privileges, 
> > not forced by sysadmin.  sys_promote is a new approach different from 
> >    
>
> The sysadmin selects the tool and writes the configuration file. So for
> the purpose of this discussion, it is effectively the same.
>
>  
>
> > selinux or sudo.  sys_promote is manipulating a already running process, 
> > while selinux or sudo is for the next launching process.
> >    
>
> Kill the process and start it again. Problem solved.
>
>  
>
> > > > 2) admins promote trusted users, so they can do some system work without knowing
> > > >  the password
> > > >
> > > >        
> > > Use sudo for that, it allows even much finer grained control.
> > >      
> > sudo may become a security problem.  Sysadmin and the user don't like 
> >    
>
> (almost) every tool may become a security problem.
> If you fear a bug in sudo, then write a minimal setuid wrapper for
> yourself which checks for the user it started and exec's a binary (with
> the full path name specified).
> And even then - dependent on other details of the setup - you have the
> gap of security problems (or misuse) because of holes in the security.
>  

But if we make sure a tool doesn't introduce any new secrutiy problem, 
that's good enough.

>  
>
> > the user's account
> > always have priorities.  My sysadmin Hommel says this to me:
> >    
>
> What does the user do if the process terminates (for whatever reason)
> and must be restarted by the user (manually or auutomatically)?
>  

If we worry that, we'd make a persistent OS instead.

> Basically I can see no need for "one time in history" actions. A daemon
> can terminate and must be restarted (it may even be a software bug that
> causes this and this doesn't change anything that the daemon's admin
> must restart it *now*). The machine may reboot for whatever reason ....
>  

The US space shuttle certainly can auto pilot, so it doesn't need a 
control panel.
And If anything fails, NASA  just launch another ship?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/