On Thu, 2006-01-26 at 03:42, Joerg Schilling wrote:
> 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.Yep I understand that bit now. > 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. > 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. > > 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? Yes thats what I'd love to do. > 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. > 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. > 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 ? > > 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. 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 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. -- Darren J Moffat _______________________________________________ opensolaris-code mailing list [email protected] https://opensolaris.org:444/mailman/listinfo/opensolaris-code
