NewFeature: Persistance of Special Roles

Discuss and suggest new grsecurity features

NewFeature: Persistance of Special Roles

Postby hmhansolo » Sun Mar 06, 2005 10:34 pm

I am using grsecurity on a desktop machine. I run stuff like gimp and wierd open source programs.. i am always testing out new stuff.. and installing new programs.. as a result, my grsec_acl is never perfect.. i am always having to fine tune it.. for exmaple: when I install new stuff, when an already protected program is used in a new/different way.. or when i update programs, and they act differently.. need access to different files.. etc..

well.. that means, every day, I am adapting my acl at least 10 times (normally much more often).. the problem that I am having, is that each time, I need to reload the acl using gradm... and as a result, anything that I have running in a special role dies or messes up, because they are dropped down to the regular user root which has almost no permissions...

can a feature be implemented, that when a `gradm -R` is done, that processes running in gradm special roles are still running in that special role after the reload.. perhaps this should be just a feature.. if you wanted a soft reload of just the acl, versus a hard reload of the entire grsec system..


also, while I wrote this, i thought up another issue that may want to be resolved.. its not as important.. but it is important to eventually get to.. everytime i upgrade a program, I have to retune the acl to give the program more access, because the updated version wants access to more files.. however, at the same time, that new updated version may not access some files, which the old version did access.. I have no way of telling, because only accesses which are denied are logged.. so there is no way to tell if a program has access to files that it doesnt or shouldn't access anymore.. eventually, as a result, after many sequential updates of a program, the acl for that program will be much more bloated than it should be.. i don't see how this problem can be addressed.... perhaps with more sophisticated learning.. specifically for the task of fine tuning an already existing acl..



lemme know what u think.. thanks


--hmhansolo
hmhansolo
 
Posts: 32
Joined: Mon Jan 10, 2005 9:15 pm

Re: NewFeature: Persistance of Special Roles

Postby hmhansolo » Wed Dec 15, 2010 2:48 am

Hello All,

Is there an update regarding persistence of special roles through a gradm reload: i.e. through a soft reload (perhaps this means a policy merging feature), or specifically recording state of the processes and their associated roles before the disable and applying roles which haven't changed onto the same processes after the enable.
hmhansolo
 
Posts: 32
Joined: Mon Jan 10, 2005 9:15 pm

Re: NewFeature: Persistance of Special Roles

Postby spender » Mon Dec 27, 2010 8:00 pm

It's at the top of my TODO list, though I plan for the soft-update to be usable in more cases than the limited set you mentioned. The goal is for the policy updating to alleviate almost any general need to issue a full reload. So you'll be able to modify subjects, add/remove objects, add new roles, remove roles, modify roles allowed IPs lists -- all without a full reload. Perhaps it would be useful to implement the weaker form of this in the meantime. I'll see what I can do.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm


Return to grsecurity development

cron