taking feature requests

[spender]

To do local only roles, just add:
role_allow_ip 0.0.0.0

below your role definition.

-Brad

[spender]

2.0 allows you to place special ACLs on specific groups. I also plan on implementing TPE as a role mode.

-Brad

[aldem]

2.0 allows you to place special ACLs on specific groups. I also plan on implementing TPE as a role mode.

What about adding specific ACLs to users (uids)? And controlled way to calculate them. Say, I can define order in which ACL(s) takes precedence in case if there are multiple defintions (one for UID, one for GID etc).

ACLs for specific IPs (sessions) also would be nice, but this was mentioned before if I remember correctly

[siti]

An idea is to add a flag the makes all children of a certain process inherits the parents acl.

A good use of this would be in gentoos "emerge", you could define an acl so all the children inherit flags to stop pax working on them. (this is because I have found a number of problems with running pax while emerging programs such as glibc). Also it could improve security, width devfsd it wants to modprobe frequently. Because you don't want any person (even root) /programs to be able to insert a module in the kernel but you want devfsd to be able to do this.


Another completly different idea is that it should be optional for a "default" acl. This is because I use grsecurity to stop remote attacks. So I define all my daemons that open ports up to have "/ h" except to what they need. This is basically like chrooting it (but much easier). So a remote attacker could only fiddle with this process because it is secured. But when you have to make a default acl with all of the security attrubutes required, it makes it difficult to set up, it has taken me days to get the system useable but I still have warnings etc.
I would guess most people would not use grsecurity with acls because of this having to define a default acl!
I also fail to see the point how it would be more secuire (remotly) with the hole system being acled.
Away around this at the moment is just to define the default ACL with learning mode but I would guess performance would be harmed and there are so many log messages;)

edit: Another idea is an option to print warning messages to just the logger not the current terminal. It gets so fustrating with all these messages, especially when setting up acls!!

[goodbyte]

A thing I've been thinking about is 'template' acls.

Problem: For the moment I have several hidden directories/files in /etc, and some programs that need read access to /etc, but not to the hidden files. Thus I need to edit several locations when I change acl for a file in /etc.

Solution: Some kind of template (that optionally can be overridden) which can be included in the object list.

Example:

Code: Select all

template "template1"
  /etc/shadow h
  /etc/gshadow h
  /etc/pam.d h

subject /bin/login
  include_template "template1"
  /etc/pam.d r


I guess one can do a cheap variant of this by using include files, but it would not be The Right Way(TM). Suggestions?

[axehind]

How about a list of messages that are put out when bad things are attempted?

For example:
What message is put out when a attempted buffer overflow happens?
What message is put out when a use tries t write to a file he shouldnt be writing to?

This is so we know what to parse the logs for.

axehind

[spender]

look at grmsg.h: all messages are in that file.

-Brad

[russelr]

I'm working on time support for acls like in LIDS, as well as improved documentation(anyone interested in writing docs please contact me), and inheritance levels.

This seems to be an old message...but I'll reply anyway.

I noticed your project in the current issue of SysAdmin and was intrigued enough to try it out for myself. While I haven't completed installation, I note that your documentation could use a little spiffing up. (The main .pdf seems to be somewhat sparse without a lot of detail.)

I'm a software engineer myself and fairly proficient with English. (Good vocabulary, good writing skills.) Since I have a little free time, I would be willing to write up some user documentation if it would help your project. (For your review, of course.)

I know almost all users appreciate good accessible security documentation.

Regards,
Russ

[spender]

Russ-

That would be very helpful. Email me at spender@grsecurity.net and we can discuss it further.

-Brad

[MichaelN]

A helpful tool would be a tool to create ACLs dynamicly/seperately from the gradm. Ie, ./gr-acl-generate /var/log/grsecurity /etc/grsec/new_acl

Just a suggestion.

[Cyt0plas]

A helpful tool would be a tool to create ACLs dynamicly/seperately from the gradm. Ie, ./gr-acl-generate /var/log/grsecurity /etc/grsec/new_acl

Just a suggestion.

I think I understand what he's getting at, this could be useful.

[devillinux]

One of my users was requesting a feature, which I think should be part of grsecurity.
The extracted patch is here:
ftp://ftp.devil-linux.org/pub/devel/testing

And here's the mail:
*******************************

I was reading the release notes for Fedora (the latest version of RedHat's
consumer product - in beta). It had the following comment
(http://fedora.redhat.com/docs/release-notes/):

------------------

The Fedora Core 0.94 kernel now makes it possible to prevent the loading of
kernel modules. This can be useful for system administrators wanting to
ensure that only a strictly-controlled set of modules are loaded. To disable
kernel module loading, issue the following command:

echo off > /proc/modules

Once this command has been issued, all further attempts to load kernel
modules will fail.

NOTE: Once kernel module loading has been disabled, a reboot is required to
re-enable it.

------------------------

And I was thinking - wouldn't this be a useful feature for Devil-Linux?
After all - we are [presumably] running a "static" environment. So once a
system is booted, wouldn't we WANT to prevent the loading (and/or changing)
of kernel modules?

[Sleight of Mind]

Why use modules at all if you want to disable them later? Just compile the stuff you need into the kernel and turn off module support, that has nearly the same effect.

[devillinux]

I agree with you in general.

BUT it is not always possible that you can go entirely without modules.
Distributions (like Devil-Linux) have to use modules, since we don't know the hardware configuration of our users and a big fat Kernel with everything in there is not an option.

Heiko

[jbridge21]

I was thinking about using the chroot jail feature to set up some virtual servers. The only obvious thing missing to be able to do this properly would be a way to restrict all processes within a chroot to bind to a given IP address. How difficult might this be?