Joerg/Dmitry:
On 07/30/10 12:10 PM, joerg.schill...@fokus.fraunhofer.de wrote:
"Dmitry G. Kozhinov"<d...@desktopfay.com> wrote:
sound-juicer is started by a non-root user the process runs as root and writes
its files as root
If this is true, this is a huge security hole. Someone should investigate the
problem. As far as I could understand, Sound Juicer does not know root
password, however bypassing this somehow. Total crash of all UNIX ideas.
There are several similar problems in GNOME.
They are a result from the fact that Linux is not security oriented when
allowing to send SCSI commands to devices. This can be done as normal
user on Linux for many SCSI commands. People develop on Linux and create
non-portable code that is a security risk.
The problem with sound-juicer is similar to that of brasero. The
sound-juicer application uses the brasero library to support CD burning.
Since both brasero and sound-juicer require this, they both are
configured in /etc/security/exec_attr to have elevated permission
when the user has "Desktop Removable Media User" profile. This profile
is normally assigned to the "Console User" role.
This, and the security implications were discussed in the brasero ARC
case (LSARC 2009/201).
There was some talk in the Tamarack (PSARC 2005/399) case about adding
some additional more fine-grained privileges (uscsi_full and uscsi_user)
to better address this. Note this quote from that case:
> We propose:
>
> - eliminate smserverd, make libsmedia open device directly;
> - create two new privileges:
> - uscsi_full for full uscsi access;
> - uscsi_user for limited uscsi access (no resets or aborts);
> - add uscsi_user to the "Basic User Profile";
However, this has
Since sound-jouicer now cleanly calls cdda2wav in order to read AUDIO data from
CD, there should no longer be a need to run sound-juicer as root.
The GStreamer CDDA plugin uses cdda2wav for playing audio from the CD.
However, CD ripping is handled by the brasero library, which uses the
SCSI commands and therefore requires the elevated privilege.
Brian
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
