Rich access control lists

Posted Oct 22, 2015 0:04 UTC (Thu) by fandingo (guest, #67019)
In reply to: Rich access control lists by dlang
Parent article: Rich access control lists

> Anything important like that sort of log data, I want off on a separate machine.

I already addressed this in a previous comment.

>> Additionally, you'd use this exact same append-only policy on the files that syslog does write, making your point moot.

Wherever that data hits disk, it's advantageous to be able to restrict to `append_data`, even when that writing is happening on a separate system.

Rich access control lists

Posted Oct 22, 2015 0:09 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

> Wherever that data hits disk, it's advantageous to be able to restrict to `append_data`, even when that writing is happening on a separate system.

advantageous, yes

but worth how much in the face of the added complications, bugs and performance hit?

Also, to make use of this, the applications are going to have to be modified in linux-only ways. Some apps won't care, but others try to be cross platform, so this sort of churn won't be welcome.

Rich access control lists

Posted Oct 22, 2015 0:56 UTC (Thu) by fandingo (guest, #67019) [Link]

> but worth how much in the face of the added complications, bugs and performance hit?

It's worth 42. I don't know how to answer the obviously loaded, rhetorical question. You'll need to offer data about performance implications before I'll get into that topic; it's just FUD otherwise.

> Also, to make use of this, the applications are going to have to be modified in linux-only ways. Some apps won't care, but others try to be cross platform, so this sort of churn won't be welcome.

For the most part, this isn't something that applications will interact with at all. (I suppose beyond EACCESS when there is a violation, but they have to deal with that anyways.) It will be handled just like SELinux policy: The Linux distribution writes and maintains it.

There is specialized software that may need to interact with Richacl specifically, but I just don't see it being a major problem. The only places where it may cause a problem is when a project is sloppy with it's open(2) mode flags, which should be tightened regardless of Richacl. If a piece of software is diligent, writing a policy for that software package isn't any challenge.