public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: Is writing to /dev/ramdom a security flaw (vserver project)
  2001-10-19 22:23 Is writing to /dev/ramdom a security flaw (vserver project) Jacques Gelinas
@ 2001-10-19 21:38 ` Christopher Friesen
  2001-10-20  0:26 ` David Wagner
  1 sibling, 0 replies; 3+ messages in thread
From: Christopher Friesen @ 2001-10-19 21:38 UTC (permalink / raw)
  To: Jacques Gelinas; +Cc: Linux kernel list

Jacques Gelinas wrote:
> 
> I have announced a project (see my signature) to run several virtual servers
> on a single box (single kernel as well). The vservers are real linux distribution
> running in a chroot/chbind/chcontext and capability limited environment.
> 
> While looking at the kernel we found out that writing to /dev/random is
> not controlled by any capability. We are providing a /dev/random in
> the vservers with permission 644, so it can be used.
> 
> Is this a security issue if an administrator of a vserver is allowed to write
> in /dev/random ?

My understanding is that anything written to /dev/random is stirred into the
pool without incrementing the entropy count.  Thus, it shouldn't be an issue.

Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Is writing to /dev/ramdom a security flaw (vserver project)
@ 2001-10-19 22:23 Jacques Gelinas
  2001-10-19 21:38 ` Christopher Friesen
  2001-10-20  0:26 ` David Wagner
  0 siblings, 2 replies; 3+ messages in thread
From: Jacques Gelinas @ 2001-10-19 22:23 UTC (permalink / raw)
  To: Linux kernel list

I have announced a project (see my signature) to run several virtual servers
on a single box (single kernel as well). The vservers are real linux distribution
running in a chroot/chbind/chcontext and capability limited environment.

While looking at the kernel we found out that writing to /dev/random is
not controlled by any capability. We are providing a /dev/random in
the vservers with permission 644, so it can be used.

Is this a security issue if an administrator of a vserver is allowed to write
in /dev/random ?

Looking at the source, it seems that it just increase the entropy and should
not be an issue. I am no expert in randomness.

If this is an issue, then a capability must exist to limit that (CAP_SYS_ADMIN
I guess).

Thanks!

---------------------------------------------------------
Jacques Gelinas <jack@solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Is writing to /dev/ramdom a security flaw (vserver project)
  2001-10-19 22:23 Is writing to /dev/ramdom a security flaw (vserver project) Jacques Gelinas
  2001-10-19 21:38 ` Christopher Friesen
@ 2001-10-20  0:26 ` David Wagner
  1 sibling, 0 replies; 3+ messages in thread
From: David Wagner @ 2001-10-20  0:26 UTC (permalink / raw)
  To: linux-kernel

Jacques Gelinas  wrote:
>Is this a security issue if an administrator of a vserver is allowed to write
>in /dev/random ?

If you're talking about write(2), it should be safe, since the entropy
count is not affected.  If you're talking about doing an ioctl(2) on
/dev/random, this is risky (since root can modify the entropy counter),
but it looks like all those code paths are protected by a capability
check, so my guess is that you're probably ok this, too.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2001-10-20  0:26 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-10-19 22:23 Is writing to /dev/ramdom a security flaw (vserver project) Jacques Gelinas
2001-10-19 21:38 ` Christopher Friesen
2001-10-20  0:26 ` David Wagner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox