Casper, Casper.Dik at Sun.COM wrote: >> In a nutshell, this is what I had wanted to do: >> >> 1. Remove Basic Solaris User from /etc/security/policy.conf > 2. Configure Apache2 to use an RBAC profile for execution > > And what is executed under RBAC? The apache startup script? > > (the pfexec property is not inherited) > >> Thereby, I was hoping to force Apache2 to only use those commands >> that I specified could be run. Since I am required to give the >> Apache2 service - proc_fork/proc_exec (the latter because it calls >> a shell script which starts the real service), then I wanted to be >> able to more tightly control what it could exec(2). > > Ah, but RBAC only intervenes when it execs through a profile > shell and not when it does system() or execve(). > > (That is something that falls naturally out of my implementation)
Definitely agree. I suppose in theory I could call the Apache2 start script (/lib/svc/method/http-apache2) using pfexec in the Apache2's start/exec property... but things are getting ugly fast. >> So, when I do this, the server goes into maintenance mode. I am >> basically trying to figure out why. >> >> Looking over this a bit more, I am not sure if this is possible >> giving the current implementation in nv72. Can someone confirm? > > Possibly not and the fact that you need to edit the global > policy.conf is pretty much a non-starter to me. It is definitely not pretty which is why I filed this: 6192137 need ability to remove individual user authorizations This title should be changed however to remove both auths and profiles. >>>>> Also, is there a way to set an audit context for a SMF-managed >>>>> service? >>> To expand on what Tom said: We could add audit flags to the >>> method_context. Or some other property group. I'm not sure >>> that would be of general use. Services should not generally >>> be audited. Services in general should audit in the requestor >>> context, if at all. >> Why do you think that this would not be of general use? Would it >> not be good to track what files your Apache2 (in this case) service >> is accessing/modifying/deleting and whether it is reaching "out of >> bounds"? I would think that events such the family of execs and >> file access events would be of great interest to a lot of people >> and by enabling a way to specify them through SMF - now you have >> an easy and repeatable way to ensure auditing is enabled for your >> (and your third party) applications. > > Yes, but this is exactly what Fine Grained Access Privileges are > being designed for. They will allow you to specify which execs > are allowed and which are not. > > In principle you could also log all entries which are failed by the > policy; the goal is the allow the policy to be specified in SMF. > > The current implementation's debugging output should give some > idea of what is going on: > > Override approved from pid = 101246, uid = 21782, priv needed = > "file_dac_read" > for /etc/shadow > > (In this particular case I allow the use of the file_dac_read privilege > solely for the file /etc/shadow) Now this is some very cool stuff! When can I get to play with it??? >>> Today one could configure any audit necessary in the method >>> using auditconfig -setpmask >> Yes, but I have to run that manually which is not really in the >> spirit of SMF. What if a service was restarted? Would it retain >> its audit mask? > > Does this suggest the need for a feature to set the audit mask through SMF? IMHO, I think so. > Or is this just a debugging thing and could you just as well use dtrace? No, it is more than that. The audit portion of this would be useful as it would integrate into a customer's audit framework (or tools that they layer on top of Solaris audit). The goal would be to better understand what actions are being taken on their systems - by their users/roles as well as services. g
