>Jarrett > >Yes I assigned the user scott the net_bindmlp priv in the SMC so its >"always on" so to speak.
I don't think you can do "always on" You can only assign it to scott when running listed programs. Even "all" is only a certain list (which can be added to.) If one of your programs is not on the list (/usr/bin, /usr/sbin, etc) in the smc then you may need to add it or else put it into one of those dirs then add the new program or subtract and add the directory. Also I don't know about TX but I suspect that, like TS8, you need all the libraries you call to be trusted per crle or else you lose your privs. Back in TS8 grandchildren tended to lose privs but I think the implementation is quite different in TX so I don't know about that. But the cure was always to add privs to the children and grandchildren in the profile. > >Manually starting the serviceX executable works/uses the privilege. > >When serviceX is started from the shell scripts/series of execve's its >like the user did not have the privilege any more and fails with the >13:permission denied on the bind operation. > >Scott > >Jarrett Lu wrote: >> Scott Gaetjen wrote: >>> I am running a daemon process, serviceX owned by an account >>> scott:staff, in the global zone on a Solaris 10 (U3) system with >>> Trusted Extensions installed. The port this daemon is listening on is >>> a MLP port listed for both the shared and private addresses in >>> tnzonecfg. >>> >>> The account scott:staff has the net_bindmlp privilege added to >>> default basic setup in /etc/user_attr. When I start serviceX >>> executable directly as the account scott, I do not see any problems. >>> >>> However, there is a use case I have where the executable can be >>> called through a series of forked processes as follows: >>> >>> 1. shell script Y starts >>> 2. java application A that execve???s >>> 3. executableA which execve???s >>> 4. serviceX executable >>> >>> In this scenario I see an error 13: permission denied error. If the >>> serviceX port is not an MLP port I do not see this error for this >>> scenario. >>> >> >> At this point, it appears that you no longer has the net_bindmlp >> privilege. >> You won't see this in the non-MLP case because only MLP requires such >> privilege. >> >>> This does not seem to be the expected behavior. I cannot observe any >>> real/effective user change or lack of privileges in the flow of the >>> indirect use case based on output from truss/ppriv that would explain >>> the problem. I was thinking maybe it???s a Java security issue. I have >>> not seen evidence that TX changes the security behavior of the Java >>> VM in this way based on its implementation in the OS kernel only. I >>> know there there are integration APIs for Java programs to get label >>> information. >>> >> >> I don't have an answer to your question yet. But I like to confirm that I >> understand you correctly. You started out with the net_bindmlp privilege. >> After a series of execve's, you lost this privilege by the time you need >> to bind to the MLP. Did I get this right? >> >> Thanks. >> >> Jarrett >> >>> If anyone can point to a specific limitation or control or patched >>> bug in TX that might cause/contribute to this behavior I???d appreciate >>> any input/advice. >>> >>> Thank you for your time >>> >>> Scott >>> >>> _______________________________________________ >>> security-discuss mailing list >>> security-discuss at opensolaris.org >> > >-- >Oracle >Scott Gaetjen | Technical Director | 1.650.607.1945 (w) | 1.703.728.1301 >(m) >Oracle National Security Group >1910 Oracle Way | Reston, VA 20190 >_______________________________________________ >security-discuss mailing list >security-discuss at opensolaris.org
