lkml.org 
[lkml]   [2009]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC: disablenetwork facility. (v4)
Hi!

> >"I can't see" is not strong enough test, I'd say.
> >
> >For example, I can easily imagine something like pam falling back to
> >local authentication when network is unavailable. If you disable
> >network for su...
> >
> >It would be also extremely easy to DoS something like sendmail -- if
> >it forks into background and then serves other users' requests.
>
> Pavel,
>
> I spent some time this afternoon reflecting on the scenarios that you sketched
> above. This reflection resulted in three concrete responses:

There's more. You are introducing security holes. Don't.

> 1. Anyone depending on their network for authentication already has to deal
> with availability faults. disablenetwork doesn't change anything
> fundamental there.

Actually it does. Policy may well be "If the network works, noone can
log in locally, because administration is normally done over
network. If the network fails, larger set of people is allowed in,
because something clearly went wrong and we want anyone going around
to fix it."

> 2. Anyone able to use disablenetwork to block a privilege escalation via su
> or to influence sendmail will be able to disrupt the privilege escalation
> or mail transfer by manipulating the ancestors of su or sendmail in plenty
> of other ways including, for example, via ptrace(), kill(), manipulation
> of PATH, manipulation of X11 events and IPC, manipulation of TTYs, and so
> on.

Please learn how setuid works. No, you can't ptrace su. Yes, su has to
deal with poisonous PATH. setuid programs are generally carefully
written to handle _known_ problems. You are adding disablenetwork that
they'll need to handle, and that's bad.

> 3. As I pointed out before, disablenetwork _is_ controlled by a build-time
> configuration option, its use _is_ still subject to any existing MAC

CONFIG_ADD_SECURITY_HOLE is still bad idea.

You should either:

a) make disablenetwork reset to "enablenetwork" during setuid exec

or

b) disallow setuid execs for tasks that have network disabled.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


\
 
 \ /
  Last update: 2009-12-28 11:13    [W:1.572 / U:0.924 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site