taking feature requests

[PaX Team]

Couldn't pax be included as a capability?

yes, it could be done as gr_set_proc_label() is called early enough during exeve() so PaX could take the flags from the ACL system.

[asok]

I would love to have two things:
- Roles (or at least something similar, e.g. users could be subjects in ACLs)
- nested ACLs.

[hightower]

I would love to have two things:
- Roles (or at least something similar, e.g. users could be subjects in ACLs)
- nested ACLs.

this will be in 1.9.8

ciao, Marc

[maynard]

I would like to see a restriction of who/w usage so shell users can't see who is logged in

Regards
Maynard

[hightower]

I would like to see a restriction of who/w usage so shell users can't see who is logged in

Regards
Maynard

chmod 700 /usr/bin/w
chmod 700 /usr/bin/who



ciao, Marc

[maynard]

chmod 700 /usr/bin/w
chmod 700 /usr/bin/who



ciao, Marc

ohhh didn't realize it was so simple thanx a lot

Maynard

[spender]

not quite. You need to restrict access to /var/log/wtmp and /var/run/utmp.

-Brad

[dj]

i realy like grsecurity! i run it on all of my boxes.

i want some new features..

only root should use df ,something like "restricted to user"

and i want a feature like "bind user to IP" so an user should use just one IP on the box.


/dj

[j0]

flamingice mentioned it earlier. I just want to say yes this would be a great idea. Similar to locking the settings for grsecurity, include a sysctl setting to disallow loading new modules. But then again this may be a false sense of security, one could just change the settings and restart. (I don't make use of ACLs btw)

my 2c,
___
dan

[arouse]

Well, it seems that tripwire-like features are not in the cards according to the posts I've read as there seems to be other solutions/workarounds.

But I've thought about tripwire and think it is necessary in a system that has an unrestricted super-user (the root of all evil). Wouldn't the argument made against MD5 sum checking also be made to work for the tripwire executable, to make it return a false negative on an altered file? Hard but doable I think.

It seems to me that, even with ACL's, the account that installs and updates software (a necessary account) is the one that can <b>still</b> alter a file. In that case something like tripwire comes in handy.

I've had an idea for a better tripwire (although the idea is based on what already exists. Look at signed java applets.)

Wouldn't it be better to add a section to the ELF file (I <i>think</i> it can be done without the executable becoming non-portable) that contains a public key signature of the executable. The checking key resides somewhere on the machine while the signing key resides off the machine. No database needed. Every time the executable is <u>first</u> opened for reading/exec the signature is checked. Executables with no signature get executed as always.

Harder to forge, no database to create/calculate, maintain, protect, protection is continous. Moreover, there is never any need for the signing key to ever be present on the machine: it can be done elsewhere.
There is, however, still a need for a database but a much more simpler one. A simple text file (or ELF file) that contains the list of paths of protected files that is itself signed. In this way the simple attack of removing the signature section and then altering the executable can avoided.

What do you guys think?

[PaX Team]

if i understood you properly, your threat model is one where you trust the guy who signs the executable (package) but not the one who actually puts it on the machine. couldn't you simply solve this problem by giving the second guy no direct write access to the filesystem, but instead have him use sudo (or something like that) to run an installer with the necessary privileges that would then verify the signature before actually putting the stuff into the system? this way the untrusted guy couldn't forge such a signed package nor could he directly mess with the file system.

[arouse]

Using sudo would certainly be a solution but I don't see the problem.

What is important is that there be a separation of duties which are then performed with the least possible privileges. Each administrator must be trusted to certain varying degrees. This has to be done if you are to have humans doing anything at all on a system.

Sudo is great, but is a bandaid. We need something like grsecurity with roles (a great enhancement to add someday btw).

My post was not motivated by a desire to see this added to grsecurity (I've read the previous posts that there other ways to achieve similar protection with ACLs) but only to address some annoying shortcomings in tripwire (and other similar tools ?). First, it seems wrong to me to have to schedule a check every so often; a computer could do <i> a lot</i> "every so often" ... like replace the infected binary with the trusted one and schedule the replacement after the check and repeat until caught -- the Arouse attack let's call it but not because it is novel: its rather basic (you can't schedule tripwire checks regularly but must make random checks to avoid this attack). Maintaining and creating a database just adds complexity IMO. I hate to have to care for and feed yet another subsystem. And RTFM for yet another product, waste of space, and blah blah blah.

I believe my idea is just about as simple as the file integrety check can get. The only other refinement would be to implement this idea in the filesystem itself. The signature could reside in some extended attribute field. The filesystem that will have this first (if the idea is any good at all) will be reiserfs. At least, I think it is the only one with the infrastructure (reiserfs4 I mean). Actually, I think that this is <b>exactly</b> where this belongs, in the filesystem.

I.hate.tripwire. Let's stop talking about tripwire-oid non-solutions. Let's go for stronger grsecurity. If someone can alter a critical file you are fucked in more ways than one anyway.

Talking about reiserfs, just had an idea. How about files that 'appear' only at specified times? Directory is empty during the day but at night the files appear. Uuouu! Sound cool? Sorry, off topic.

Which leads to a cool grsecurity feature to have: time enabled ACLs. Like, you can read the file only during working hours but not at any other time. You will be able to do X up until time Y.

[spender]

i don't think the ACLs should belong on the filesystem itself. It doesn't make for pretty configuration....when you have everything together in one place you have more of an idea of what is going on. Plus, when the actual state of the security system is stored in files, it's much easier to break that kind of system than one where the state is all stored in kernel memory. One requires simply to find a hole in the configuration, the other requires a compromise of the kernel. As for time based ACLs, I think it's a decent idea...the problem with it is how is it stored? I haven't yet been able to find an efficient way to do it. time based ACLs don't really fit into any model. You'll notice that LIDS' handling of time-based ACLs is basically a hack....it doesn't have any structure to it. Once you figure out how to handle it, how do you search it? since it should support ranges of course, is there any way other than linked lists? I don't think it's immediately clear how it can be done, and since these would have to be checked on every access, I don't find an O(n) algorithm to be an acceptable solution.

-Brad

[arouse]

Hmm. I can see that I was rambling on and on.

I was not talking about putting the ACLs on the filesystem but the signature/checksums. Still, I see nothing wrong with the ACLs being there. If unauthorized changes to your filesystem can be made ... isn't it game over anyway?
Oh, and I think that in reiserfs4 you will be able to have (or be able to extend) attributes per file that can also be made to appear to be a single editable file. Sort of like making every line and every field of /etc/passwd a separate file with separate ACLs yet still be presentable as a single text file to those programs that require such a thing.

As for the time based ACLs: I am not familiar at all with the guts of LIDS/grsecurity so I can't comment one way or the other. However, it seems to me (this is the naive point of view) that a time based ACL is no 'different' from an ordinary ACL. The set of ACLs make a tree which the decision procedure traverses looking for an excuse to grant access (right?). Well, why not have a cron-like process insert and remove time based ACLs at the appropiate times in the tree? The inserted, time based ACL will have no time constraints to be checked. The time constraints are only the interest of the cron-like process which inserts and removes them.

Betcha this scheme makes the LIDS hack look golden ... or it may <i>be</i> the LIDS hack for all I know.

BTW, could you say a little something about how file based systems are easier to crack than kernel based systems? Isn't the kernel for the next reboot a file in the filesystem?

[spender]

Well, in systems that I've seen that do this kind of thing, the files containing ACL info are put in several places on this system. From a strictly statistical standpoint, this increases the chances of the administrator making a stupid mistake. In grsecurity, we enforce that important things be protected (like kernel images), we won't allow you to use the system if they aren't.

About the EA/reiserfs stuff.....none of that is done on the virtual filesystem level. We want the ACL system to operate regardless of the architecture of the system and the filesystem people are using.

We do things completely different than everyone else in grsecurity. ACLs are implemented through hash tables. A match is determined by traversing down the directory tree of the object, until a match is found for it in the ACL hash tables. We then check if the requested access is within the allowed access for the subject, and deny/allow based on that. We don't have complex decision trees...we simply have one method of determining a match. As for inserting and removing individual ACLs, we probably won't ever support that. It's a very expensive operation since we're using hash tables. We would have to resize the hash table every time it got an unacceptable ratio of used entries to table size, which involves reinserting every entry in the table. Also, inserting rules like you suggested would open up another hole for an admin to make a stupid mistake.

-Brad