[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#262507: ITP: resmgr -- resource manager library

On Thu, Oct 28, 2004 at 08:46:18PM +0200, Julien BLACHE wrote:
> >> I plan to have SANE built with resmgr support for Etch, and I hope
> >> other applications will support resmgr too. It can make life a lot
> >> easier, and changes to the code are really minimal.
> >
> > It is, however, a security hole; it's functionally equivalent to
> > pam_console (which we declined to ship in the past) and has the same
> It's a bit better than pam_console, however, which has a lot of
> issues.
> I uploaded to experimental to get some feedback on the possible
> security issues/implications; I'm still trying to determine whether
> there are holes (read: bigger holes than those which can exist with
> other solutions) or not.
> Could you point out the security issues you see in resmgr ?

The primary one is the same as pam_console: once you have an fd open,
you can keep it open for as long as you like. So all the fancy
restrictions on when you can open a device don't actually do anything;
if you can open it at any time, you have effective access, reducing it
to the same level of security as group permissions.

(Doing something about this would require either a genuine userspace
*proxy*, or kernel support; there's a few proposals floating around
about how pam_console could have done it right).

While it may make sense on some public terminals or demonstration
systems, you do not want it on hosts where device security is

[Also, it's a liability to have a process running as root which opens
devices and then hands fds over to non-root processes; it could form
part of a privilege escalation attack. So you don't want it running
without a good reason].

> I note that SuSE ships resmgr and has a couple of resmgr-enabled
> applications. Of course, RedHat ships pam_console, so that's not a
> point (and they're having a whole lot of problems with it, again).

Yes, they just don't care. Secure-by-default isn't really a priority
for them. If you run a server on suse then resmgr is one of those
things you have to go through and rip out, like pam_console on redhat.

>  - resmgrd isn't installed by default, you need to explicitly install
>    it (no dependencies, only a Recommends that could be downgraded to
>    a Suggests to avoid side-effects with some frontends to apt);

I'd say that's the really important one; we need to keep it that way.

>  - resmgrd won't be started until configured (no default config
>    is shipped in the package, only an example config file);

And that's probably a good idea too (along with documentation that
clearly states what it does and does *not* do).

> > (Why somebody bothered to implement resmgr instead of simply enhancing
> > pam_console is beyond me; probably NIH)
> If you haven't already, you might want to read
> <http://rechner.lst.de/~okir/resmgr/description.html>

Yeah, they gave up on the puzzle of how to fix pam_console without
really trying. It's not as hard as they made it look; mostly you just
have to add hotplug support, and have pam_console itself record the
current user in a file or process someplace. Quite ironically, the
solutions to the problems they cite for pam_console are exactly the
same as the solutions they implemented for resmgr. Hence I figure it
was probably NIH.

  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

Attachment: signature.asc
Description: Digital signature

Reply to: