Darren J Moffat <[EMAIL PROTECTED]> wrote:
> > 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/
>
> Sure and I think it is a good discussion point. However I don't
> believe it helps for shell script and my current shell script
> hack is really ugly.
Agreed, but I was looking for a solutions for binaries.
> > 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.
>
> Why don't you want to change the application ? Is it because
> you don't want any Solaris specific code in there ? I suspect
> it is and thats a fine answer it will just help me understand
> your position.
There are two reasons:
- While I could change cdrecord, there may be a lot of applications
where the authors/maintainers don't like to change their code
and it it would be cool to have a solution that allow most applications
to take advantage from fine grained privs.
- All my tools typically compile/work on ~ 30 different platforms.
15 of them seem to be still activley marketed. If all these platforms
decide to implement an incompatible way of dealing with fine grained
privs, the source will become unreadable at security relevent places.
> > Does this mean that Trusted Solaris did have extended attributes that
> > did more than 'suid some-user'?
>
> Yes it does. It has MAC labels, and two privilege sets. The two
> privilege sets are forced privileges and allowed privileges. If
> a binary has no allowed privileges it can never get privileges by
> any means. The allowed privilege area is covered in a much better
> way by the limited set in the OpenSolaris implementation.
I heard that the next Trusted Solaris implementation will only add a few things
to Solaris 10. Does this mean that it will use the current open privs
implementation?
> > 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.
>
> Agreed, and while it remains an unused empty container it is useless
> in my opinion.
OK, so I a not the only personwith that impression.
> > Once this has been done, programs like star could find a OS independent way
> > of
> > archiving extended attributes.
>
> I don't follow your logic here. Why do we need to use the attributes
> so that you know how to back them up ? Is it that you are saying that
> OpenSolaris should agree with other implementations on the names of
> certain attributes and what data goes in them ?
No, the problem is that Linux e.g. implements an interface that forces star
to know more about the content than I like.
If the interface would be defined the right way, then star would not need this
special OS dependent know how.
Other OS started to implement more features from NFSv4 and by doing that,
Linux will implement at least a NFS client for Solaris extended attributes.
This is a big chance to talk with other platforms and to define a unified
framework.
> > Well, I really like fine grained privs and I like to start avoiding
> > suid-root
> > programs where ever possible.
>
> The whole point of the privilege bracketing is that it is making
> setuid safe. The use of setuid attribute on the file is just a
Let us say "safer".
> crutch for our lack of storing the fine grained list of privileges
> in a file system attribute. Even with that you should still consider
> doing the privilege bracketing if you want make the code as secure.
> However I do understand if you don't want OS specific code in some
> programs.
For the reasons mentioned above.
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
