>
>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)
>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.
>>>> 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)
>
>> 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?
Or is this just a debugging thing and could you just as well use dtrace?
Casper
