Darren J Moffat <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-01-25 at 07:04, Joerg Schilling wrote:
> > If you like to transparently run a privileged rootl-less
> > program, you currently need to use a profile enabled shell (e.g. pfsh,
> > pfksh,
> > pfcsh). Otherwies you would need to call:
> >
> > /usr/bin/pfexec command args
> >
> > pfexec.c is nearly 600 lines of code.
>
> 600 lines of very very carefully implemented and hand audited code!
The 50 lines from isaexec do not seem to cause a lot of time to audit for
possible security problems. The 600 lines from pfexec are much more complex and
thus harder to check.
> > How about adding aprox. 50 lines from isaexec to pfexec to allow doing the
> > following:
> >
> > link /usr/bin/pfexec to /usr/bin/cdrecord
> > copy cdrecord to /usr/bin/i86/cdrecord
> >
> > then call /usr/bin/cdrecord and get a cdrecord with a few added privs listed
> > in /etc/security/exec_attr
>
> Do you actually need multiple implementations of cdrecord, eg a 32bit
> and 64 bit version ? If not I don't think abusing the isaexec mechanism
> is the best way to solve this problem. Sure it will work but it doesn't
> feel the best way to me, but I'm thinking about it.
Well, after I had the idea of finding a way to avoid the need for a pf*sh
because e.g. GUI applications may call popen("cdrecord .....", ...),
I found that there should be another way to hide pfexec than by using a pf*sh.
I am using the idea of isaexec only because it provides a nice and already
introduced way of placing the "real" binaries in a different location than
/usr/bin/
> Thanks for thinking about this and looking for a solution.
>
> The other way is for cdrecord to "reexec" itself under pfexec.
> We have a few shell scripts around here that do this as the very
> first thing:
>
> if [ "$_" != "/usr/bin/pfexec" -a -x /usr/bin/pfexec ]; then
> /usr/bin/pfexec $0 $*
> exit $?
> fi
This seems to work because of ksh dealing with an environment var $_.
> You could have cdrecord do the same thing. Ugly ? yes. d\Does it help
> all programs in general like your suggestion could ? no. Is is better
> than what you suggested, I don't think so but I'm throwing it out for
> further discussion.
Do you propose that cdrecord (being a binary - not a shell script) should
set an environmental var to flag the next instance that it has been called
by pfexec already?
I am not sure if I should like this solution as I am trying to find a solution
that avoids to change applications for fine grained privs whereever possible.
> I'd like to solve this problem in a better way. That might be
> changing the userland bits of the exec*() family to do the pfexec
> prefixing in userland first or it might mean getting the kernel
> involved. Or it might be something else.
So you like to completely hide pfexec from other sources?
> I think what you are looking for in the specific case of cdrecord
> is really forced privileges in the filesystem, right ? This is
> because I think cdrecord is one of those class of programs that needs to
> ALWAYS run with privielge. We had that ability
> in all previous Trusted Solaris releases because we had a modified
> version of UFS and tmpfs. In the OpenSolaris code base we only
> have forced all privileges, as implemented by being setuid root.
Does this mean that Trusted Solaris did have extended attributes that
did more than 'suid some-user'?
> If we had a way to have a system namespace for extended attributes
> this would be possible to implement in tmpfs, UFS and ZFS (and any
> other filesystem that implements the xattr ability).
This brings me to one of my other concerns with OpenSolaris:
Linux and FreeBSD seem to have xattr implementations that allow to tag
system.* attributes that are honored by the OS. The current Solaris extended
attribute implementation is just a currently empty container and nobody seem to
know how to use it as nobody defined how to use it in a globally accepted way.
Once this has been done, programs like star could find a OS independent way of
archiving extended attributes.
> For your specific case of cdrecord you could also code it to
> be installed setuid root and drop all of the privilege you don't
> need. See ping.c as an example of how to do this and this security
> community document for the commentary:
> http://opensolaris.org/os/community/security/library/howto/privbracket/
Well, I really like fine grained privs and I like to start avoiding suid-root
programs where ever possible.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-code mailing list
[email protected]
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
