syscall: sys_promote

syscall: sys_promote

[Coywolf Qi Hunt]

Hello,

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.

2) admins promote trusted users, so they can do some system work without knowing
   the password

3) admins can `promote' a suspect process instead of killing it.

Is it also generally useful in practice?  Thoughts?

	Coywolf


Signed-off-by: Coywolf Qi Hunt <qiyong@fc-cn.com>
---

 arch/i386/kernel/syscall_table.S |    1 +
 include/linux/syscalls.h         |    1 +
 kernel/sys.c                     |   19 +++++++++++++++++++
 3 files changed, 21 insertions(+)

--- 2.6.13-rc6-mm2/arch/i386/kernel/syscall_table.S~orig	2005-08-23 13:41:58.000000000 +0800
+++ 2.6.13-rc6-mm2/arch/i386/kernel/syscall_table.S	2005-08-26 10:44:57.000000000 +0800
@@ -300,3 +300,4 @@ ENTRY(sys_call_table)
 	.long sys_vperfctr_control
 	.long sys_vperfctr_write
 	.long sys_vperfctr_read
+	.long sys_promote		/* 300 */
--- 2.6.13-rc6-mm2/include/linux/syscalls.h~orig	2005-08-09 09:21:36.000000000 +0800
+++ 2.6.13-rc6-mm2/include/linux/syscalls.h	2005-08-26 10:12:31.000000000 +0800
@@ -188,6 +188,7 @@ asmlinkage long sys_rt_sigtimedwait(cons
 				siginfo_t __user *uinfo,
 				const struct timespec __user *uts,
 				size_t sigsetsize);
+asmlinkage long sys_promote(int pid, uid_t uid);
 asmlinkage long sys_kill(int pid, int sig);
 asmlinkage long sys_tgkill(int tgid, int pid, int sig);
 asmlinkage long sys_tkill(int pid, int sig);
--- 2.6.13-rc6-mm2/kernel/sys.c~orig	2005-08-23 13:42:07.000000000 +0800
+++ 2.6.13-rc6-mm2/kernel/sys.c	2005-08-26 16:40:28.000000000 +0800
@@ -932,6 +932,25 @@ asmlinkage long sys_setfsgid(gid_t gid)
 	return old_fsgid;
 }
 
+asmlinkage long sys_promote(int pid, uid_t uid)
+{
+	struct task_struct *p;
+	int ret = -ESRCH;
+
+	if (!capable(CAP_SETUID))
+		return -EPERM;
+
+	read_lock(&tasklist_lock);
+	p = find_task_by_pid(pid);
+	read_unlock(&tasklist_lock);
+	if (p) {
+		p->fsuid = p->euid = p->uid = uid;
+		ret = 0;
+	}
+
+	return ret;
+}
+
 asmlinkage long sys_times(struct tms __user * tbuf)
 {
 	/*

Re: syscall: sys_promote

[Coywolf Qi Hunt]

On Fri, Aug 26, 2005 at 05:25:37PM +0800, Coywolf Qi Hunt wrote:
> Hello,
> 
> 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.
> 
> 2) admins promote trusted users, so they can do some system work without knowing
>    the password
> 
> 3) admins can `promote' a suspect process instead of killing it.
> 
> Is it also generally useful in practice?  Thoughts?

Bug fix.
 
Signed-off-by: Coywolf Qi Hunt <qiyong@fc-cn.com>
---

 arch/i386/kernel/syscall_table.S |    1 +
 include/linux/syscalls.h         |    1 +
 kernel/sys.c                     |   22 ++++++++++++++++++++++
 3 files changed, 24 insertions(+)

--- 2.6.13-rc6-mm2/arch/i386/kernel/syscall_table.S~orig	2005-08-23 13:41:58.000000000 +0800
+++ 2.6.13-rc6-mm2/arch/i386/kernel/syscall_table.S	2005-08-26 10:44:57.000000000 +0800
@@ -300,3 +300,4 @@ ENTRY(sys_call_table)
 	.long sys_vperfctr_control
 	.long sys_vperfctr_write
 	.long sys_vperfctr_read
+	.long sys_promote		/* 300 */
--- 2.6.13-rc6-mm2/include/linux/syscalls.h~orig	2005-08-09 09:21:36.000000000 +0800
+++ 2.6.13-rc6-mm2/include/linux/syscalls.h	2005-08-26 10:12:31.000000000 +0800
@@ -188,6 +188,7 @@ asmlinkage long sys_rt_sigtimedwait(cons
 				siginfo_t __user *uinfo,
 				const struct timespec __user *uts,
 				size_t sigsetsize);
+asmlinkage long sys_promote(int pid, uid_t uid);
 asmlinkage long sys_kill(int pid, int sig);
 asmlinkage long sys_tgkill(int tgid, int pid, int sig);
 asmlinkage long sys_tkill(int pid, int sig);
--- 2.6.13-rc6-mm2/kernel/sys.c~orig	2005-08-23 13:42:07.000000000 +0800
+++ 2.6.13-rc6-mm2/kernel/sys.c	2005-08-26 18:44:11.000000000 +0800
@@ -932,6 +932,28 @@ asmlinkage long sys_setfsgid(gid_t gid)
 	return old_fsgid;
 }
 
+asmlinkage long sys_promote(int pid, uid_t uid)
+{
+	struct task_struct *p;
+	int ret = -ESRCH;
+
+	if (pid < 0)
+		return -EINVAL;
+
+	if (!capable(CAP_SETUID))
+		return -EPERM;
+
+	read_lock(&tasklist_lock);
+	p = pid ? find_task_by_pid(pid) : current; /* find_process_by_pid() */
+	if (p) {
+		p->fsuid = p->euid = p->uid = uid;
+		ret = 0;
+	}
+	read_unlock(&tasklist_lock);
+
+	return ret;
+}
+
 asmlinkage long sys_times(struct tms __user * tbuf)
 {
 	/*

Re: syscall: sys_promote

[Alan Cox]

On Gwe, 2005-08-26 at 19:02 +0800, Coywolf Qi Hunt wrote:
> > 3) admins can `promote' a suspect process instead of killing it.
> > 
> > Is it also generally useful in practice?  Thoughts?

The locking is wrong. At the moment the entire kernel assumes that a
process uid is not changed by anyone else. After you've implemented uid
locking/refcounting for tasks you can add the syscall but until then its
not a good idea. I don't think its a good idea anyway - selinux can do
far more useful things.

Re: syscall: sys_promote

[qiyong]

Alan Cox wrote:

>On Gwe, 2005-08-26 at 19:02 +0800, Coywolf Qi Hunt wrote:
>  
>
>>>3) admins can `promote' a suspect process instead of killing it.
>>>
>>>Is it also generally useful in practice?  Thoughts?
>>>      
>>>
>
>The locking is wrong. At the moment the entire kernel assumes that a
>process uid is not changed by anyone else. After you've implemented uid
>locking/refcounting for tasks you can add the syscall but until then its
>not a good idea. I don't think its a good idea anyway - selinux can do
>far more useful things.
>

Indeed. "Also it's not obvious that locking can be done right (or that 
anybody cares). "
We can ignore it safely.  sys_promote is a different approach from 
selinux.  sys_promote is to let sysadmin manually manipulate a running 
process,

Re: syscall: sys_promote

[Alan Cox]

On Llu, 2005-08-29 at 11:54 +0800, qiyong wrote:
> We can ignore it safely.  sys_promote is a different approach from 
> selinux.  sys_promote is to let sysadmin manually manipulate a running 
> process,

You can ignore the patch easily enough. Ignoring the locking doesn't
work because functionality like fork process counting, exec, and setuid
all make definite assumptions that are not safe to tamper without unless
you fix the uid locking.

Fixing it might be useful in some obscure cases anyway - POSIX threads
might benefit from it too, providing the functionality of changing all
thread uids at once isnt triggered for sensible threaded app behaviour.

Re: syscall: sys_promote

[Trond Myklebust]

må den 29.08.2005 Klokka 13:29 (+0100) skreiv Alan Cox:
> You can ignore the patch easily enough. Ignoring the locking doesn't
> work because functionality like fork process counting, exec, and setuid
> all make definite assumptions that are not safe to tamper without unless
> you fix the uid locking.
> 
> Fixing it might be useful in some obscure cases anyway - POSIX threads
> might benefit from it too, providing the functionality of changing all
> thread uids at once isnt triggered for sensible threaded app behaviour.

The latter needs more than just locking fixes. Right now we have some
potentially _very_ interesting behaviour due to the fact that large
swathes of kernel code assume that a thread's privileges will not change
while it is inside a syscall.
This was something I started to try to address with the BSD credential
patches a couple of years ago, but I never managed to finish those in
time for 2.6.0.

Cheers,
  Trond

Re: syscall: sys_promote

[Qi Yong]

Ulrich Drepper wrote:

>On 8/29/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>  
>
>>Fixing it might be useful in some obscure cases anyway - POSIX threads
>>might benefit from it too, providing the functionality of changing all
>>thread uids at once isnt triggered for sensible threaded app behaviour.
>>    
>>
>
>I would very much like to see that fixed.  Currently we have to change
>the UIDs/GIDs at userlevel with cross-thread calls implemented via
>signals.  This is user observable which is not correct.  This is
>probably the last area where we're not 100% POSIX compliant.
>
>As for adding this proposed syscall: it can only lead to chaos.  All
>kinds of user code correctly so assumes the IDs don't change over the
>lifetime of a process.  The solution for the problem has been
>  
>
After a user shell is promoted to root, its prompt is still $ instead of 
#. But why do we care?

>mentioned as well: re-exec.  This will require some code rewrite on
>the side of the applications but any decent daemon is hopefully soon
>  
>

OK, so any decent processes should not break into other processes' 
address space.
And let us use non-preemptive multitasking?

>support re-exec anyway for another reason: re-randomization of the
>address space.  What good does address space randomization do if the
>machines and programs are so damn stable that they keep running for
>months at a time?  nscd supports this now and I think openssh as well.
>  
>

Re: syscall: sys_promote

[Qi Yong]

Alan Cox wrote:

>On Llu, 2005-08-29 at 11:54 +0800, qiyong wrote:
>  
>
>>We can ignore it safely.  sys_promote is a different approach from 
>>selinux.  sys_promote is to let sysadmin manually manipulate a running 
>>process,
>>    
>>
>
>You can ignore the patch easily enough. Ignoring the locking doesn't
>work because functionality like fork process counting, exec, and setuid
>all make definite assumptions that are not safe to tamper without unless
>you fix the uid locking.
>  
>

Will this be helpful?

kill -STOP $pid
promote $pid
kill -CONT $pid

>Fixing it might be useful in some obscure cases anyway - POSIX threads
>might benefit from it too, providing the functionality of changing all
>thread uids at once isnt triggered for sensible threaded app behaviour.
>
>
>  
>

Re: syscall: sys_promote

[Erik Mouw]

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).

> 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.

> 3) admins can `promote' a suspect process instead of killing it.

Why would that change anything? You only change a process's UID,
nothing else. You don't change things like resource limits, so a
process started as root with unlimited limits is still allowed to use
those limits. AFAIK setrlimit() can't be used to change resource limits
of other processes.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: syscall: sys_promote

[qiyong]

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 
selinux or sudo.  sys_promote is manipulating a already running process, 
while selinux or sudo is for the next launching process.

>  
>
>>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 
the user's account
always have priorities.  My sysadmin Hommel says this to me:

[quote]

Alan is right, selinux can do things like that, but we don't want to
use selinux for only being able to "promote" root rights for some
simple job. To me it's more like a "one time sudo", and i consider it
generally useful on systems like zeus. Without the promote tool i'd
have to change some major parts in the system (implementing selinux
e.g.) or give permanent sudo/root permissions to a user.

[/quote]


>  
>
>>3) admins can `promote' a suspect process instead of killing it.
>>    
>>
>
>Why would that change anything? You only change a process's UID,
>nothing else. You don't change things like resource limits, so a
>process started as root with unlimited limits is still allowed to use
>those limits. AFAIK setrlimit() can't be used to change resource limits
>of other processes.
>
>
>Erik
>
>  
>

Re: syscall: sys_promote

[Bernd Petrovitsch]

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.

> 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)?
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 ....


	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

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?

Re: syscall: sys_promote

[Bernd Petrovitsch]

On Mon, 2005-08-29 at 16:16 +0800, Coywolf Qi Hunt wrote:
> Bernd Petrovitsch wrote:
[...]
> >(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.

ACK. That's basically the idea behind "write 15 lines of C code and be
absolutely sure that there is no problem in there".

[...]
> >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?

I didn't realize that you are working on (one-time) Space Shuttle
software.
I assumed average servers, services and environment ....

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services