11:33 p.m.
What is the policy/guidelines around having Set UID executables in
Fedora?
I maintain libsmbios. Libsmbios has to read the system DMI/SMBIOS table
to do its job, and this table can currently only be obtained by
mmap()-ing /dev/mem. I also need to read certain areas of RAM to get
teh Dell system id, which is not in the DMI tables. I would like to make
some of this available to non-root users, but the only way I can think
of do do this involves SUID executables.
Can anybody suggest a better way?
My current problem is in the dellsysidplugin.py yum-plugin. It can only
get the Dell system ID if yum is run by root. This means that some yum
commands, such as 'yum list' will give different output when run as
root/non-root.
--
Michael Brown
11:39 p.m.
On Mon, Apr 09, 2007 at 11:33:52PM -0500, Michael E Brown wrote:
What is the policy/guidelines around having Set UID executables in
Fedora?
I maintain libsmbios. Libsmbios has to read the system DMI/SMBIOS table
to do its job, and this table can currently only be obtained by
mmap()-ing /dev/mem. I also need to read certain areas of RAM to get
teh Dell system id, which is not in the DMI tables. I would like to make
some of this available to non-root users, but the only way I can think
of do do this involves SUID executables.
Can anybody suggest a better way?
<http://lists.freedesktop.org/archives/hal/2006-March/004770.html>
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
2:34 a.m.
On Mon, 2007-04-09 at 23:33 -0500, Michael E Brown wrote:
My current problem is in the dellsysidplugin.py yum-plugin. It can
only
get the Dell system ID if yum is run by root. This means that some yum
commands, such as 'yum list' will give different output when run as
root/non-root.
A setuid executable is often frowned upon, but note that if written
properly it can be secure and even useful. E.g. if you have an
executable that _only_ retrieves your system id it should be fine to
make it setuid as long as the system id isn't a secret that only root /
console users should know. There's also consolehelper (for the time
being) if you want to restrict it to console users... perhaps the system
ID is something that only console users should know.
Btw, the rant of mine that Matthew pointed to was more concerned with
the sad fact that we run a bunch of X11 apps as root.. Just don't run
any X11 apps as root; it's a really really bad idea, thanks :-)
David
6:59 a.m.
On Tue, Apr 10, 2007 at 03:34:23AM -0400, David Zeuthen wrote:
Btw, the rant of mine that Matthew pointed to was more concerned
with
the sad fact that we run a bunch of X11 apps as root.. Just don't run
any X11 apps as root; it's a really really bad idea, thanks :-)
Yeah but it's such a good rant. :)
And seriously, although X is the most obviously scary, the same thing
applies to any setuid code beyond the incredibly trivial.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:41 a.m.
On Tue, Apr 10, 2007 at 07:59:14AM -0400, Matthew Miller wrote:
On Tue, Apr 10, 2007 at 03:34:23AM -0400, David Zeuthen wrote:
> Btw, the rant of mine that Matthew pointed to was more concerned with
> the sad fact that we run a bunch of X11 apps as root.. Just don't run
> any X11 apps as root; it's a really really bad idea, thanks :-)
Yeah but it's such a good rant. :)
And seriously, although X is the most obviously scary, the same thing
applies to any setuid code beyond the incredibly trivial.
Well... the getSystemId executable I want to run is _not_ a GUI app, and
the executable only takes two parameters that I can turn off if real uid
!= effective uid, effectively making it a program that outputs only with
no user input.
The information returned is not secret info. Basically just saying what
the Dell system ID is (not available in HAL currently), plus a couple
other things that can already be gotten through HAL.
I'll see what I can do, and if I end up doing SUID, I'll post it for
review before I stick it in my RPM.
I'm investigating HAL and DBUS now. It may prove to be an excellent
alternative if I can wrap my head around all of it.
--
Michael
10:11 a.m.
Matthew Miller wrote:
On Tue, Apr 10, 2007 at 03:34:23AM -0400, David Zeuthen wrote:
> Btw, the rant of mine that Matthew pointed to was more concerned with
> the sad fact that we run a bunch of X11 apps as root.. Just don't run
> any X11 apps as root; it's a really really bad idea, thanks :-)
Yeah but it's such a good rant. :)
And seriously, although X is the most obviously scary, the same thing
applies to any setuid code beyond the incredibly trivial.
And this is where I don't get the rant, afaik system-config-xxx aren't suid
root, they call a (one would assume audited) helper program to become root, by
use of the root password, so there is no chance for privelidge escalation here,
because the user has the root password, the user cannot get any more
privilidged then that AFAIK. So where is the problem?
Regards,
Hans
10:28 a.m.
On Tue, Apr 10, 2007 at 05:11:36PM +0200, Hans de Goede wrote:
And this is where I don't get the rant, afaik system-config-xxx
aren't
suid root, they call a (one would assume audited) helper program to become
root, by use of the root password, so there is no chance for privelidge
escalation here, because the user has the root password, the user cannot
get any more privilidged then that AFAIK. So where is the problem?
Theoretically, one can configure these programs to allow authentication as a
user other than root, including sudo-like reauth-as-self operations. That
would be very useful functionality. In fact, it'd be reasonable to configure
many of them on desktop systems to be allow local use without any password
prompt.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:49 a.m.
On Mon, 2007-04-09 at 23:33 -0500, Michael E Brown wrote:
What is the policy/guidelines around having Set UID executables in
Fedora?
I maintain libsmbios. Libsmbios has to read the system DMI/SMBIOS table
to do its job, and this table can currently only be obtained by
mmap()-ing /dev/mem. I also need to read certain areas of RAM to get
teh Dell system id, which is not in the DMI tables. I would like to make
some of this available to non-root users, but the only way I can think
of do do this involves SUID executables.
Can anybody suggest a better way?
Exposing the SMBIOS table as a device would be a start. There's
precedent for drivers that do little else besides map a specific region
of memory, since /dev/mem is just way too coarse-grained.
- ajax
10:18 a.m.
On Tue, Apr 10, 2007 at 10:49:41AM -0400, Adam Jackson wrote:
On Mon, 2007-04-09 at 23:33 -0500, Michael E Brown wrote:
> What is the policy/guidelines around having Set UID executables in
> Fedora?
>
> I maintain libsmbios. Libsmbios has to read the system DMI/SMBIOS table
> to do its job, and this table can currently only be obtained by
> mmap()-ing /dev/mem. I also need to read certain areas of RAM to get
> teh Dell system id, which is not in the DMI tables. I would like to make
> some of this available to non-root users, but the only way I can think
> of do do this involves SUID executables.
>
> Can anybody suggest a better way?
Exposing the SMBIOS table as a device would be a start. There's
precedent for drivers that do little else besides map a specific region
of memory, since /dev/mem is just way too coarse-grained.
I had an actual kernel patch in one linus -rc kernel to export smbios
table as a sysfs entry. The backlash generated prompted me to withdraw
the patch.
AFAICT, userspace should be able to do this itself. SUID is one way. I'm
currently looking at docs for HAL and DBUS as another. I'm leaning
towards HAL/DBUS, but they are semi complex and I'll need some help
making sure I get it right.
--
Michael
11:32 a.m.
On Tue, Apr 10, 2007 at 10:49:41AM -0400, Adam Jackson wrote:
Exposing the SMBIOS table as a device would be a start. There's
precedent for drivers that do little else besides map a specific region
of memory, since /dev/mem is just way too coarse-grained.
Now let me see. A device driver is more privilged than a setuid binary and
more attackable. It can't be swapped and it is hard to change as part of
the kernel.
Why is a device driver better for this ?
If its unchanging data then I'd dump it somewhere from an init script and
at that point no setuidness is needed.
1 p.m.
On Tue, 2007-04-10 at 12:32 -0400, Alan Cox wrote:
On Tue, Apr 10, 2007 at 10:49:41AM -0400, Adam Jackson wrote:
> Exposing the SMBIOS table as a device would be a start. There's
> precedent for drivers that do little else besides map a specific region
> of memory, since /dev/mem is just way too coarse-grained.
Now let me see. A device driver is more privilged than a setuid binary and
more attackable. It can't be swapped and it is hard to change as part of
the kernel.
Why is a device driver better for this ?
It's a comparable amount of code either way, the auditing is trivial,
changes require a package update either way, and /dev/mem is a bad API
whose use we should not be encouraging. I am unconvinced by your
reasoning here.
I'm not interested in arguing though.
- ajax
6262
days inactive
6262
days old
10 comments
6 participants
participants (6)
-
Adam Jackson -
Alan Cox -
David Zeuthen -
Hans de Goede -
Matthew Miller -
Michael E Brown