|
Home > Archive > Debian Developers > October 2004 > Bug#262507: ITP: resmgr -- resource manager library
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Bug#262507: ITP: resmgr -- resource manager library
|
|
| Julien BLACHE 2004-07-31, 7:49 am |
| Package: wnpp
Severity: wishlist
* Package name : resmgr
Version : 1.0
Upstream Author : Olaf Kirch <okir@suse.de>
* URL : http://rechner.lst.de/~okir/resmgr/
* License : GPL
Description : resource manager library
>From the README :
This is a resource manager that will provide unprivileged users
access to device files. This is a common problem for people
writing hardware drivers etc that should be used by "ordinary"
users, such as usb cameras, scanners, CD writers, audio devices,
etc etc.
resmgr is composed of a library for client applications, a daemon that acts
as a proxy between the application and the actual devices, and a PAM module
that tells resmgr to open (and close) a session when a user logs in (and
out).
Users are granted the right to use devices based on classes of devices defined
in resmgr's configuration. resmgr also integrates with hotplug.
Applications that want to use resmgr needs patching, but this is really
straigthforward. You do not necessarily need to have resmgr up and running to
use an application that makes use of it; if resmgr isn't available, it's of
course still possible to access the device directly (depends on how the
application was written).
resmgr will be broken up into 4 packages : resmgr (daemon), libresmgr$SONAME
(library), libresmgr-dev, libpam-resmgr.
I'm currently working on the packaging and testing resmgr with SANE; there's
a fairly simple patch for SANE floating around, that is really non-intrusive
and already used by SuSE. IIRC there's another one for libusb.
I won't upload resmgr before Sarge releases, but will probably make test
packages available depending on how things go.
People willing to audit resmgr for security issues are welcome, as stated on
resmgr's homepage.
JB.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.2-rc1-ben1
Locale: LANG=C, LC_CTYPE=fr_FR@euro
--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Julien BLACHE 2004-10-27, 5:53 pm |
| Hi,
For those of you interested, I've uploaded resmgr 1.0-1 to
experimental (must go through NEW, etc.).
I'll upload a version of sane-backends built with resmgr support to
experimental when sane-backends 1.0.15 will be released (end of next
week, IIRC).
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.
Comments, patches and testers welcome.
Description (from libresmgr1) :
The resource manager library was designed to ease the use of device
nodes in desktop setups, where users should be able to access e.g.
scanners, CD or DVD burners, etc.
| |
| Andrew Suffield 2004-10-28, 5:52 pm |
| On Wed, Oct 27, 2004 at 05:03:43PM +0200, Julien BLACHE wrote:
> For those of you interested, I've uploaded resmgr 1.0-1 to
> experimental (must go through NEW, etc.).
>
> I'll upload a version of sane-backends built with resmgr support to
> experimental when sane-backends 1.0.15 will be released (end of next
> week, IIRC).
>
> 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
problems. As such it's not really an improvement in security over
making devices group- or world-accessible.
resmgr must not be enabled by default and should carry a big warning;
you can only use it in scenarios where you would be willing to use
pam_console.
(Why somebody bothered to implement resmgr instead of simply enhancing
pam_console is beyond me; probably NIH)
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
| |
| Julien BLACHE 2004-10-28, 5:52 pm |
| Andrew Suffield <asuffield@debian.org> wrote:
Hi,
>
> 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 ?
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).
> problems. As such it's not really an improvement in security over
> making devices group- or world-accessible.
It doesn't claim to be a more secure solution than fiddling with
ownership and permissions, only to be more convenient (and I tend to
think that it is).
> resmgr must not be enabled by default and should carry a big warning;
> you can only use it in scenarios where you would be willing to use
> pam_console.
As it is currently :
- rsm_open_device() will fall back to a call to open() if resmgrd
isn't available, so resmgr-enabled applications do not depend on
resmgrd being up & running;
- 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);
- resmgrd won't be started until configured (no default config
is shipped in the package, only an example config file);
- you need to add pam_resmgr to your PAM config files by hand.
I will add the big blinking warning if/when it goes into unstable (if
there's a consensus against resmgr, I'll withdraw the ITP) if needed.
> (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>
I'm still reviewing resmgr and I probably won't be done with it for
some more months (being low on free time). I won't upload to unstable
unless I'm sure it cannot harm and it isn't a gapping security hole.
The idea is to provide a tool to sysadmins who might want to use it,
and not something that works out of the box, with a half-broken
default config.
Thanks for your feedback,
JB.
--
Julien BLACHE - Debian & GNU/Linux Developer - <jblache@debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andrew Suffield 2004-10-28, 5:52 pm |
| On Thu, Oct 28, 2004 at 08:46:18PM +0200, Julien BLACHE wrote:
>
> 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
important.
[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).
>
> 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/ |
`. `' |
`- -><- |
| |
| Julien BLACHE 2004-10-31, 2:47 am |
| Andrew Suffield <asuffield@debian.org> wrote:
Hi,
[...security implications of fd passing]
[vbcol=seagreen]
> While it may make sense on some public terminals or demonstration
> systems, you do not want it on hosts where device security is
> important.
Of course, that's why I want to avoid having strong dependencies on
resmgrd itself, so it won't be installed behind the admin's back. It
should be possible and easy to install it, but it shouldn't be done
automagically.
>
> And that's probably a good idea too (along with documentation that
> clearly states what it does and does *not* do).
This documentation needs to be written, I'll add that to my todo list.
I still need to have a closer look at the code before anything serious
happens (= upload to unstable).
JB.
--
Julien BLACHE - Debian & GNU/Linux Developer - <jblache@debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|