[lkml]   [2010]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/3] Security: Implement disablenetwork semantics. (v4)

> >You can trivialy make disablenetwork disable setuid exec, too. That
> >will introduce better isolation facilities, but not introduce any new
> >security problems.
> >
> >For some reason, you don't want to do the obviously right thing.
> I don't want to do it because it's not "obviously right" to me: I *have*
> setuid
> programs that I want to be able to raise privileges when network-disabled.
> I *don't have* any setuid programs that will be harmed by disablenetwork.

Well, I do not have any desire to use disablenetwork, but I do not
want my users to use it and DoS sendmail.

> Examples of software that I want to be able to gain privileges normally
> include:

You'll have to make sure those are not accessed from the
disablenetworked parts, I'd say. Pre-existing unix domain socket
should be the way to go.

> rainbow, which requires privilege in order to add new accounts to the
> system
> and in order to call setuid() but which does not require networking
> privileges.
> qmail-queue, which uses setuid to deliver mail that it reads from fd 0 to
> local users
> and other old favorites like mount, fusermount, X, and, presumably, any
> audio
> software that wants to go realtime.

mount certainly wants network access for NFS.
(cesky, pictures)

 \ /
  Last update: 2010-01-11 13:03    [W:0.120 / U:1.744 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site