linux-kernel - Re: RFC: disablenetwork facility. (v4)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 2 Jan 2010 06:28:04 +0000 (UTC)
From:	daw@...berkeley.edu (David Wagner)
To:	linux-kernel@...r.kernel.org
Subject: Re: RFC: disablenetwork facility. (v4)

Eric W. Biederman wrote:
>daw@...berkeley.edu (David Wagner) writes:
>> When you talk about DOS, let's be a bit more precise.  disablenetwork
>> gives a way to deny setuid programs access to the network.  It's not a
>> general-purpose DOS; it's denying access to the network only.  And the
>> network is fundamentally unreliable.  No security-critical mechanism
>> should be relying upon the availability of the network.
>
>The audit daemon should not rely on netlink?

auditd is not a setuid-root program.  It is launched at boot time.
(If that's what you're referring to.)

I'm personally not very worried about attacks on a setuid-root program
that leave it unable to log messages to the audit log.  I personally
find it hard to get very concerned about that scenario.  And if there
is a setuid-root program where it is absolutely vital that the log
messages get through, then the setuid-root program probably ought to
be checking return values and acknowledgements anyway, regardless of
whether disablenetwork is in place or not.

>For me the case is simple.  I have seen several plausible sounding
>scenarios that get most of the way there.  I know I am stupid when
>it comes to security and that people exploiting problems are going
>to be looking harder than I will.  Therefore I think there is
>a reasonable chance this will introduce a security hole for someone.

OK.  I'm not opposed to introducing some way to disable setuid
execution, to give folks a greater comfort level.  I still am not
convinced it's necessary (I personally suspect it to be unnecessary),
but if it is the necessary political compromise to enable the Linux
kernel to better support privilege separation and sandboxing,
so be it.  Whatever it takes to get that support in place is
worthwhile.  So, thank you for working out how to implement such
a mechanism!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/