Re: Security through Permissiveness: A Zen Riddle?

pollardat_private

Shane Kerr <shane@time-travellers.org>:
> Security Gurus,
> 
> Okay, I admit I haven't actually downloaded any LSM kernel patches.  And
> I wasn't at the BOF.  In fact, I've only ever submitted a single (one
> line!) patch to the kernel.  So my concerns may be totally unfounded....
> 
> Nevertheless, I consider one of the biggest problems with Unix security
> that root permission is required by network daemons.  Consider:
> 
> NTP              - bind(), settimeofday()/adjtime()
> FTP/DNS          - bind(), possibly chroot() and setuid()
> SMTP/POP/IMAP    - bind(), read/write user's mail folders
> SSH              - bind(), setuid()
> DHCP             - bind() (and promiscous mode?)
> HTTP/IRC/syslog  - bind()
> 
> Now in some cases the application can setuid() to a non-root user, but
> not always (NTP, non-anonymous FTP, SMTP/POP/IMAP).  In the most other
> cases, the application can drop capabilities, but this is not always
> true (for SSH at least).  This does make having applications reset on
> SIGHUP difficult sometimes.  More importantly, it violates the goal of
> assigning the least amount of privilege necessary to accomplish a
> specific task.
> 
> I've seen it said over and over on this list:  security is hard and
> often programmers get it wrong simply because they're not security
> experts.  I agree!
> 
> I've touched on this before, but I figure I may as well keep trying
> until I get an answer:  Is it possible to create an LSM with the current
> proposed model that will allow me to grant only a small subset of root
> privileges to a specific executable?  If not, is there another way to go
> about this (perhaps by using other hooks and dropping privileges for the
> processes - i.e. when exec() runs "ntpd" drop all privileges except for
> bind() and adjtime(), and when that process calls bind() drop that
> privilege - yuck)?
> 
> In my mind, this is "permissive", and folks don't want to do that.  I
> think that may be a mistake - does that make any sense?

I don't claim godhood:

This should be part of the "capabilities".  The current structure is
designed to get the module accepted for kernel inclusion. To that aim
it is limited it's scope to that which can more easily be shown as
an acceptable overhead, and correct.

I do think the current capability model is insufficient to accomplish
all permissive functions that are called for (though the SELinux module
may grant a better way to define the capabilities/roles/...).

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollardat_private

Any opinions expressed are solely my own.

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module