[grsec] effective dual roles / suggested enhancements

Brad Spengler spender at grsecurity.net
Tue Jan 11 14:56:12 EST 2005


On Tue, Jan 11, 2005 at 12:17:15PM -0700, jnf wrote:
> Hi,
> 
> What I am trying to accomplish may be possible, but I am not sure. Is
> there a way to have a user match both a user role and a group role? For
> instance I have a bastion host with many users that need to access the box
> in order to hop through it, the programs and files they need access too
> are constant minus their home directories, in which they need read/write
> access to certain files within it (.profile / append to .bash_history,
> .ssh/known_hosts / etc ), In trying to get them to match against dual
> roles this seemed impossible to the best of my knowledge. At the moment I
> have a role for each user which results in a 12,000+ line policy, which
> takes about 1 minute 43 seconds to load upon issuing a gradm -E.

If possible, use non-world-accessible home directories, then all 
policies in /home can be done with /home/*/.bash_history, etc in a group 
role, and any special users can be given their own user roles.

> Writing the policy was a bit of a pain in the ass also, it would be so
> nice if macro's were supported- it would be nice to be able to define
> macro's but also have special variable along the lines of $user or similar
> so I could define one group and then do something similar to:
> 
> /home/$user/.bash_history      rac

What you're probably looking for then is already implemented as domains.  
You can also use $HOME in your policy.

> 
> In addition to that, perhaps I am doing it wrong, but it seems the
> auditing modes are broken at least in 2.0.1 (I think that was the release
> version prior to 2.1.0). Am I correct in this statement? If I am
> understanding it correctly I should be able to do something like:
> 
> /home/user       RWCDX

You're doing it wrong.  The auditing flags only enable auditing, they 
don't grant any permission.  I suppose however I could change this 
behavior, as it wouldn't break anything.

> Also, I understand that eventually, you Brad, intend to expand the regexp
> support to support character ranges, is there any probable timeline there?
> i.e. /proc/[a-zA-Z]*     r would be great.

I don't have a timeline for this, though it is on my TODO list.

-Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://grsecurity.net/pipermail/grsecurity/attachments/20050111/55b80540/attachment.pgp


More information about the grsecurity mailing list