Joerg Schilling <[email protected]> wrote:
[...]
> On Solaris, you (currently) use a profile enabled shell (pfsh, pfksh or pfcsh)
> that calls getexecuser() in order to find whether there is a specific
> treatment needed. If this specific treatment is needed, then the shell calls
> execve(/usr/bin/pfexec cmd <args>)
> else it calls execve(cmd <args>)
>
> I did recently voted to require all shells to be profile enabled by default.
Why? I asume there will only be few programs requiring to be run by a
wrapper, and mv /usr/bin/foo to /usr/pfexec-bin/foo;
echo $'#!/bin/sh\n/usr/sbin/pfexec /usr/pfexec-bin/foo "$@"' > /usr/bin/foo;
chmod 755 /usr/bin/foo
should be easier than patching e.g. all callers of cdrecord, and it won't
slow down starting non-profiled applications.
Possibly the pfexec can tell the application to be run by the basename (like
su1), in this case you'd add something like
"alias cdrecord /opt/schily/bin/cdrecord" to it's configuration and link it
to /usr/bin/cdrecord.
> With the future plans for extending fine grained privs on Solaris, sending
> SCSI commands will become more than one priv.
>
> I proposed to have a low priv right to send commands like inquiry and test
> unit ready. These commands may e.g. be send without interfering a concurrent
> CD/DVD write operation.
>
> The next priv could be the permission for sending simple SCSI commands that
> allow reading from the device.
>
> The next priv could be the permission for sending simple SCSI Commands that
> allow writing.
>
> The final priv would allow even vendor specific commands: this is what
> cdrecord needs.
That sounds reasonable, but I wonder how you can get access to a device
file descriptor in order to do unprivileged access.
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
Bodo Eggert <[email protected]> wrote:
> Joerg Schilling <[email protected]> wrote:
>
> [...]
> > On Solaris, you (currently) use a profile enabled shell (pfsh, pfksh or pfcsh)
> > that calls getexecuser() in order to find whether there is a specific
> > treatment needed. If this specific treatment is needed, then the shell calls
> > execve(/usr/bin/pfexec cmd <args>)
> > else it calls execve(cmd <args>)
> >
> > I did recently voted to require all shells to be profile enabled by default.
>
> Why? I asume there will only be few programs requiring to be run by a
> wrapper, and mv /usr/bin/foo to /usr/pfexec-bin/foo;
> echo $'#!/bin/sh\n/usr/sbin/pfexec /usr/pfexec-bin/foo "$@"' > /usr/bin/foo;
> chmod 755 /usr/bin/foo
> should be easier than patching e.g. all callers of cdrecord, and it won't
> slow down starting non-profiled applications.
Because the architecture review commitee decided this would be the right way.
Note that we are on a migration from the classical root/non-root UNIX to a fine
grained privileges handling. The current documentation says that you need to
have a profile enabled shell as your SHELL in order to be able to use a
root-less Solaris.
> Possibly the pfexec can tell the application to be run by the basename (like
> su1), in this case you'd add something like
> "alias cdrecord /opt/schily/bin/cdrecord" to it's configuration and link it
> to /usr/bin/cdrecord.
But you are right that another way would be to use something like "isaexec"
> > The final priv would allow even vendor specific commands: this is what
> > cdrecord needs.
>
> That sounds reasonable, but I wonder how you can get access to a device
> file descriptor in order to do unprivileged access.
This is something that needs to be discussed. Last night, I found that there
should be a way to run cdrecord without the need to have the "file_dac_read"
provilege. I'll discuss this with the security group.
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
On Tue, 24 Jan 2006, Joerg Schilling wrote:
> Bodo Eggert <[email protected]> wrote:
> > Joerg Schilling <[email protected]> wrote:
> > [...]
> > > On Solaris, you (currently) use a profile enabled shell (pfsh, pfksh or pfcsh)
> > > that calls getexecuser() in order to find whether there is a specific
> > > treatment needed. If this specific treatment is needed, then the shell calls
> > > execve(/usr/bin/pfexec cmd <args>)
> > > else it calls execve(cmd <args>)
> > >
> > > I did recently voted to require all shells to be profile enabled by default.
> >
> > Why? I asume there will only be few programs requiring to be run by a
> > wrapper, and mv /usr/bin/foo to /usr/pfexec-bin/foo;
> > echo $'#!/bin/sh\n/usr/sbin/pfexec /usr/pfexec-bin/foo "$@"' > /usr/bin/foo;
> > chmod 755 /usr/bin/foo
> > should be easier than patching e.g. all callers of cdrecord, and it won't
> > slow down starting non-profiled applications.
>
> Because the architecture review commitee decided this would be the right way.
>
> Note that we are on a migration from the classical root/non-root UNIX to a fine
> grained privileges handling. The current documentation says that you need to
> have a profile enabled shell as your SHELL in order to be able to use a
> root-less Solaris.
If the shell was the only program calling cdrecord, this would work out as
expected.
--
My mail reader can beat up your mail reader.