Open dragonchaser opened 1 year ago
kulmann
commented
1 year ago What about granting this privilege to the sysadmin? The sysadmin can read files anyway. In big organizations the Admin user (who can't read content of a space and can't manage members if not a member themselves) is usually not also a sysadmin, for a good reason (to block them from accessing content). But there always is a sysadmin. I'd suggest implementing a CLI command to solve this particular issue.
mmattel
commented
1 year ago @kulmann I am curious because a sysadmin would need to authenticate himself via a CLI command for security reasons. That would require also a new role. If no authentication is defined, I wonder how to prevent misuse of an completely open command line tool if you get shell access. Maybe I do not see the full picture.
On the other hand side, using a voting system as proposed minimizes the risk of misuse as all steps are logged. That alone is a big prevention as it involves n>1 users. Beside the technical view, such a capability is a sales driver/differenciator in a highly competitive market.
kulmann
commented
1 year ago I see even bigger potential for misuse in such a voting system. Imagine a teacher peer-pressuring students into voting for him getting access to a space. Sounds more likely to me than getting shell access in the first place.
The voting system leaves me with the impression of being overengineered for a problem that we don’t have yet. Introducing a permission and giving that to a special role is far easier. Then you don’t even need to do that via CLI.
kulmann
commented
1 year ago Like I said, file system access would grant all the rights to fiddle with everything at the moment. So an unprotected CLI command would be no risk increase compared to now, or am I missing something? Doesn’t make it good of course…
dragonchaser
commented
1 year ago I see even bigger potential for misuse in such a voting system. Imagine a teacher peer-pressuring students into voting for him getting access to a space. Sounds more likely to me than getting shell access in the first place.
The voting system leaves me with the impression of being overengineered for a problem that we don’t have yet. Introducing a permission and giving that to a special role is far easier. Then you don’t even need to do that via CLI.
You have the same problem with your option, the teacher would simply ask the admin to grant him access, would probably be easier than manipulating students. The risk you are sketching here is more an administrative problem, you have to pick your voters wisely.... In the scenario of a school/university/etc. you would restrict your voters to members of the faculty to avoid abuse by a single malicious actor. Which is the whole purpose of the proposal.
kobergj
commented
1 year ago The sysadmin can read files anyway.
This is not correct. One can use security measures (eg. encrypting discs) to avoid giving the sysadmin access to all files.
Imagine a teacher peer-pressuring students into voting for him getting access to a space.
Students should not be made voters. Voter should be high level representatives of the organization (ceos, presidents, prime ministers, starship captains, ...) If one can "peer-pressure" one of these persons the organization has bigger problems than orphan files
kulmann
commented
1 year ago The sysadmin can read files anyway.
This is not correct. One can use security measures (eg. encrypting discs) to avoid giving the sysadmin access to all files.
How does an encrypted disk help with that? Needs to be mounted and the sysadmin can probably access the mounted volumes. Encrypted files on disk could be a solution, but I don't see that coming... anyhow, I do agree with you guys that in the long term CLI commands should be authenticated as well. So if you proposal is a "long term solution" then authenticated CLI command is probably already a must. If you aimed for something short term it would be just "päpstlicher als der Papst".
Imagine a teacher peer-pressuring students into voting for him getting access to a space.
Students should not be made voters. Voter should be high level representatives of the organization (ceos, presidents, prime ministers, starship captains, ...) If one can "peer-pressure" one of these persons the organization has bigger problems than orphan files
I fully agree with that. But now again, someone needs to make the respective users the CEO / president / starship captain / ... and who defines the number of votes necessary for taking over an orphaned space? I guess that is likely someone who is sysadmin anyway.
What do you guys think about a permission for space membership management in combination with full audit log of space membership modifications and a notification about space membership modifications to all managers of the space (relevant for the evil case of someone sneaking into a space that doesn't match your "orphaned" criteria)?
I still get the feeling that the voting system is over-engineered.
kobergj
commented
1 year ago I fully agree with that. But now again, someone needs to make the respective users the CEO / president / starship captain / ... and who defines the number of votes necessary for taking over an orphaned space? I guess that is likely someone who is sysadmin anyway.
Not necessarily. But a sysadmin could probably change the values if they are just defined by envvars. We would need to protect changing them also. Probably with an n-key-system. Which leads to:
I still get the feeling that the voting system is over-engineered.
You are probably right. But such a system could maybe be reused for other sensitive configuration values.
What do you guys think about a permission for space membership management in combination with full audit log of space membership modifications and a notification about space membership modifications to all managers of the space (relevant for the evil case of someone sneaking into a space that doesn't match your "orphaned" criteria)?
The audit measures are anyways necessary, no matter which way we choose. But I don't feel very good having one user who can add members to all spaces at any time. Imo there needs to be some sort of verification beforehand. We could have a user role that can add managers to orphaned spaces. But then again an admin could give itself this role too sneak into an orphaned space.
kobergj
commented
11 months ago Users running into this issue now: https://github.com/owncloud/ocis/issues/7265
someone-somenet-org
commented
4 months ago This is just security theater.
If you dont trust your sysadmins, you have bigger issues at hand than lost spaces.
Arbitrary restrictions wont prevent any abuse.
On the other hand: such a design possibly makes the software ineligible to use in bigger companies, as security audits become infeasible or impossible.
kobergj
commented
4 months ago I'm sorry but I strongly disagree with everything you say.
This is just security theater.
If you dont trust your sysadmins, you have bigger issues at hand than lost spaces.
One of the most common misconceptions in software security. No, you do not NEED to trust your sysadmins. Yes, you CAN write software that is even secure with malicious admins. Malicious admins are (besides social engineering) one of the biggest threads for software applications. I strongly believe one should not give to much power to one person, as it will be abused sooner or later.
Arbitrary restrictions wont prevent any abuse.
This seems to be more of a philosophical statement. But in this special case I don't see this as an "arbitrary restriction". It is precisely tailored to our needs.
On the other hand: such a design possibly makes the software ineligible to use in bigger companies, as security audits become infeasible or impossible.
You couldn't be more wrong. Security audits will be much easier because you can see which users voted which user to become the new space manager. So if this feature is missused you see exactly who was involved.
And btw: security audits are only the snakeoil you use to avoid having to do real security. :wink:
someone-somenet-org
commented
4 months ago You need to state further axioms or assumptions, but your statement is objectively wrong in general.
Ranging from family+friends setups, (atechnical) teams/groups, small to big companies and even universities, users will absolutely have to trust their sysadmins. Either because of social standing or because of policy. This will always enable the possibility of abuse and you need policy and social norms to deal with that. That goes far beyond what any software can do.
If there is no policy and/or no means to make sure the policy is upheld abusive sysadmins have to be regarded as omnipotent attackers, who can ignore legal frameworks, will always have plausible deniability, can push arbitrary policies onto users, can severely limit the users and can prevent users from establishing external trust-anchors. From an external POV the servers, the network and the client devices are to be viewed as compromised.
Not sure how you think that it is possible to deploy a piece of software into such an environment that can prevent the omnipotent attacker from breaking security (in the commonly understood terms) of said software, because general consensus seems to be that there is no technical way to do this.
Or put in the philosophical way: There cannot be a technical solution to a social issue.
I can only think of very few very niche use cases where the users dont need to trust their sysadmins and usually these systems are not intended (and are suboptimal) for internal use, but mostly for providing a service to the general public.
Lets break this proposal:
n-Users (n>1) are defined as voters for promtion requests in case of orphaned spaces and m is a configurable quorum of voters
Who defines who the users are? Can an admin create 10 users and define these as the only eligible voters and set the quorum to 10?
Also this proposal tries to fix only a tiny portion of permission issues of spaces and for example doesnt take into consideration the administrative demotion and removal of users and groups from spaces.
I stand by my previous claim: it is security theater not solving issues, but only introducing new issues.
On the other hand: such a design possibly makes the software ineligible to use in bigger companies, as security audits become infeasible or impossible.
You couldn't be more wrong. Security audits will be much easier because you can see which users voted which user to become the new space manager. So if this feature is missused you see exactly who was involved.
Nothing prevents you to log admins grating themselves space manager rights, without all the other stuff. Disclosing who voted (and therefore disclosing who did not) in the audit log seems problematic too. Is the auditlog public or not? If not: who, but the malicious admin will ever see it?
Also software wanting to influence internal policies and hinder compliance as directed by law for no good reason is definitely a no-go for audits. :)
This "feature" is the reason why we will no longer consider ocis as a candidate for the replacement of owncloud for our 30k+ people institution as it weakens our internal policies and/or prevents us from doing our work.
I'm sorry but I strongly disagree with everything you say. [...] You couldn't be more wrong. [...]
Since you seem to want to get personal: For more than 10 years I have been part of an academic hacking team ranking consistently first or second in their country and in the top worldwide on ctftime, worked in cyber-security relevant fields and was teaching cyber-security at university. Whats your expertise? ;)
[...] to avoid having to do real security. 😉
Thats a ... "strong" statement after defending this "feature" ...
kobergj
commented
4 months ago @someone-somenet-org first of all: Sorry for overexaggerating in my response. I never meant to offend you personally nor question your expertise. I do 100% respect you and your opinion. Please accept my apologies, I really have no hard feelings against you.
Please also note that this feature is just a proposal. Until now there is no intend to implement it.
abusive sysadmins have to be regarded as omnipotent attackers
I'm not 100% convinced a sys admin always needs to be a omnipotent user. You could hypothetically have several permissions sets like system-configurator, log-reader, voter, audit-log-overseer. These roles could all be assigned to the same user (in case of a simple family/friends setup) or to multiple users in case of a big installation. A user with only one of these roles can not do as much damage as a user with all of the roles. Therefore you could use this to increase your security.
There cannot be a technical solution to a social issue.
I 100% agree. You can only have a secure system if your users do know how to behave securely. There is no away around processes for deployment and configuration. After all a sysadmin could just install a completely different build from his personal fork. But with features like this you could give your users some extra tools to stay on the right path.
If yes: why even bother?
Maybe to take work from the sysadmins? If users can self-repair their space without the sysadmin having to do something that is a win I would say.
If no: Who defines who the users are?
Good question. Also Who defines how many users there are? is a valid question. But even if sysadmins can do this (as a first iteration) they would still only have to do this once and then they cannot add themselves later.
How can this hold up with legal basics? A court requesting access to all of the files uploaded (even for files uploaded in the future) by some user is a thing.
Interesting question. I didn't think about that. What if I would store all files encrypted and store the key at the user somehow? I could not give the data out even if I wanted to. Wouldn't it be a similar case here? If I can't access the data I cannot give it to the court?
How to prevent random or disgruntled users from holding the data hostage/ransom?
Also interesting question. I would say you cannot. It is their data. They can do with it whatever they want?
How to ensure that sensitive information is not disclosed by revealing the space name and the to be added username to less trusted accounts? Disclosing this info to everyone seems like a big security and privacy issue to me.
Yes we need to avoid that :+1:
This "feature" is the reason why we will no longer consider ocis as a candidate for the replacement of owncloud for our 30k+ people institution as it weakens our internal policies and/or prevents us from doing our work.
It should not! This feature is a proposal that is NOT on any roadmap. If and when it will be implemented is unclear. And even if it is implemented there will be a simple option for installations that don't want to bother with it. (e.g. n=1).
Since you seem to want to get personal:
was never my intend. Sorry again
[...] to avoid having to do real security. 😉
Thats a ... "strong" statement after defending this "feature" ...
was just a joke. I do understand the need of having security audits. They are just used way to often as an excuse for accepting security flaws.
There are cases when a the all space-manages of a space are unable to perform their management duties on said space (e.g. death, left company, etc). In those cases the administrators of the instance need a way to add a new manager to the affected space. To prevent a malicious actor to grant those privileges to somebody without verification we propose to have an n-key-system, meaning that those actions need a defined number of votes to go into effect.
Example:
We have an orphaned spaces, usually it would fall into the responsibility of the instance admins to grant space-manager privileges to another trusted person. To avoid abuse this must not be done by only a single administrator. So the request for promoting a trusted person to space-manager for the orphaned space is created by a instance admin. n-administrators need to approve this request for the trusted person to become the new space manager.
Technical proposal:
/cc @kobergj @mmattel @micbar