Only allow specific transfers in solana - solana

I want only specific public keys/accounts (decided by votes) to be able to transfer SOL into a project account. Just anyone should not be able to transfer SOL into the project account.
The project account in question is going to be created using my solana program.
Could someone here please inform if this is TECHNICALLY FEASIBLE or not and how to go about it conceptually?

Fundamentally:
A wallet owner can use system transfer of SOL from any system owned account to any account (either system owned or program owned).
Programs can transfer SOL from any program owned account to any account (either system owned or program owned).
What you're looking for is not feasible. For example in option 1 you'd have to be in the system transfer logic to prevent transfers and for option 2 it still won't prevent what can be done by option 1.

Related

Intune Enrollment Standard Users

I am trying to enroll about a 100 systems in Intune. I want the user to be signed in as a standard user. I searched and found the only way to do this will be using AutoPilot. Thats is just not possible, It requires a factory reset device and a hardware hash for each device.
The other way they say is to run a Powershell script. That option won't work because I want only the one microsoft account on the system. Windows needs at least one Admin account.
I simply want the normal user to be a standard account and in case he needs admin privileges I can connect and type in cloud device administrator's credentials to give him access. However, I cannot find anyway to get this done, kind of hard to believe this is so difficult to do. Any suggestions?

Solana Program Executable Data Account

I'm currently learning Solana development with Rust.
I'm trying to understand why do we have a Program Account and a Program Executable Data Account. I already know that the Program Account contains a reference to a Program Executable Data Account, and that the latter contains the actual code.
My question is why do we have to split the actual code from the Program Account into a separate account? My initial thoughts were:
Maybe this has to do with being able to upgrade your program code. Maybe when you upgrade your program, a new Executable Data Account is created and the reference in the Program Account is updated.
That is not the case, since after upgrading a program, the reference (the address) to the Executable Data Account is the same.
Maybe this has to do with ownership of accounts. Maybe one account is owned by the developer and the other by the BPF Program.
That is neither the case because both accounts are owned by the BPF Program, and the developer is just the Upgrade Authority
Why do we need 2 accounts for a program? Why not store the actual code in the data slot of the Program Account?
I hope this makes sense.
I'm not 100% sure if this is the reason, but it may have to do with immutability of program accounts. The runtime enforces that program accounts are totally immutable, but when you upgrade a program, the data changes, of course. By putting it all in a separate account that is updated, you can get around that restriction.
If the original account pointed to a different data account, and we swapped data accounts on upgrade, then the runtime enforcement would break, since the public key would be modified.
A Program account (key) is the address of the Program executable. The Program executable is where the BPF code is and it is immutable unless the owner deployed with the upgradable BPF loader:
solana program deploy ...
The owner can upgrade the program using the same address
vs
solana deploy ...
When you upgrade you are using a different address. This means that the original program still exists. I believe this deployment approach is being considered for removal
Whatever way you deploy, the Program does not contain any other data and of course it can't modify its own program byte code. However; Programs can operate on the data of user accounts when the user account was created with the Program ID'd as the "owner"

Where should I store my application's "activation" key?

I've written an application and I'd like to add a registration key/serial number to it (I'm big on minimum inconvinience - ala #4 at this Eric Sink article). My question is about where to store the "activation" once the application has been registered. As I understand it, I have a trade-off between storing the key in a public place, where all users can read it (but which requires admin rights to save there) and storing a per-user activation (but then each user on the computer will have to activate independantly). That gives me two choices:
Some user, with local admin rights, activates the product. The activation is stored in HKLM, in the program files folder, or somewhere else where all users can read it, and the product is activated for all users.
A user (with or without admin rights) activates the product. The activation is stored somewhere user-centric (per-user app.config, HKCU, etc). The plus is that the user doesn't have to be an admin. The downside is that if there are 6 users who use the computer, each has to activate the product. They can each re-use the same serial, but they still have to enter it.
Is this really the trade-off? If it is, what have others done? As a developer, I'm used to people being a local admin, but in the real-world, I don't expect many of my corporate users to be local admins, which makes me lean towards option 2. Are computers not shared often enough that I shouldn't be concerned?
Again, I'm not asking about how to physically register a computer - I'm not worried about it. I'm only going to checksum the key provided and give the go-ahead, as I want to be as non-invasive as possible.
I would recommend a solution that does not require admin rights. Lots of users, especially in shared environments, won't have those rights and won't be able to find anyone with them conveniently.
Also, going forward a few years, I think it will be getting increasingly unusual to have admin rights on the computer you are using, as the security situation improves.
Registry seems to be an okay solution for business software. At least at where I used to work, regular user will not be a local computer administrator, so each installation will require local administrator account. This is a good thing since it will lessen the headache of your support staff from people installing just about everything in your business computing environment. The trade off is of course, user will be pissed that they can't install stuff or have to contact support to do it, but hey... :)
Other stuffs:
USB / other type of dongle (ala old
3DMax)
plain old text file (ala
Garmin GPS software on mobile device)
Encode them / rewrite the key into
your binary or part of your binary
(did this trick back in th old DOS
days)
Store them in your own db via web (ala EverQuest / other MMORPG games)
Local key db (ala MathLab I think)
How about using the isolated storrage for you application?
You will have the ability to store this information on a mashiene level for your registration, and the configuration changes can be persisted on a user level.
We save our activation code to the registry for the current user (HKCU) we have had very little problems with it. Our customers run on everything from home computers to thin clients on cooperate networks.
If your software will be used in schools or other educational environments you need to provide some other method. It could be as simple as a separate registration application which will save to the activation for all users. Your software would have to do two registry lookups but that is a small price to pay.
In general, most computers are used by a single user (or multiple people still using the same user account). So a user based storage will work most of the time anyway.
However it's not either/or. There are folder locations that are writable by all users - such as the ProgramData folder. The key is to make the file readable/writable by Everyone so that you can verify the content regardless of the user.
DeployLX Licensing does this for non-secure license data so that it can be used by multiple users without an admin explicitly granting permission.
You should be consistent. If administrator rights were required to install the program, it's not out of line to require administrator rights to register it. Likewise if you somehow managed to install it without administrator rights then register it without too.
If you install and register in one step this won't be an issue.

Why running a service as Local System is bad on windows?

I am trying to find out the difference between difference service account types. I tumbled upon this question.
The answer was because it has powerful access to local resources, and Network Service should be used if possible.
But still I am not able to understand that if it has powerful access to local resources, how attacker can access the account? What are the ways to compromise the account? I understood it is all about security, but I don't know how. It could be dark hacker's world, however anybody could explain, in simple terms, why network service account is better than local account ?
Thanks in advance.
Every program you run increases the attack surface of your server.
You have to assume that a determined, malicious actor can exploit bugs or loopholes in your program to make it do anything. You mitigate that by executing your programs with the least privileges required to do their jobs.
Some of these exploits include:
Luring attacks, in which an attacker tricks your program into executing their code under the program's elevated privileges.
Buffer Overrun Attacks, in which extra data sent to a method is written into adjacent memory, which may be the target of control flow logic.
Man in the Middle attacks, where an attacker falsifies messages to your program.
Often, a given service isn't obviously vulnerable to any of these. Running under network service (or another account with reduced permissions) is a 'better safe than sorry' strategy that acknowledges two important facts of software development: programmers are fallible and attackers are inventive.
The LocalSystem account is the Windows equivilant of the *nix root account. It's even more privileged than an administrator account. When you run as LocalSystem, you have full access to every resource on the machine.
As others have written, you should write your code to run with the least possible privileges.
The primary difference between LocalService and NetworkService is that services running as NetworkService have the ability to authenticate to other machines in the domain (as the machine account I believe).
Please note that the LocalService and NetworkService accounts both have the "Impersonate" privilege which is a potentially dangerous privilege - it allows the service to impersonate the user who is calling into the service. If that user is an administrator, then even though your code is running in a low privileged service, it can do anything that the administrator does. If an attacker can exploit a buffer overflow in your least privilege service, they can hook out the APIs you use to impersonate your caller and wait until a high privileged caller calls into your service. This technique is known as "Token Kidnapping" and the MSRC has a great blog post describing the issue (and contains links that describe how to mitigate many of the other risks associated with using LocalService and NetworkService accounts).
The Local account has effectively full administrative priviledges on the local machine. Hence any code that might escape from say a buffer overrun and get itself executing has significant scope to do damage.
On the other hand, the Network Service account has by default only Guest level access to the local system. Hence even if an attacker managed to find way to send and execute code within the service that code would have limited access.
If your service has a bug, which can allow attacker to execute arbitrary code (like buffer overflow), he can do everything with your computer if service is running under Local System account, which is equivalent to Administrator account. So the lesser priveleged account your service is running, the lesser privilege the attacker can get.
The simplest scenario is when the service allows the user of the service to execute some code on command line. For example MS SQL Server has a stored procedure that allows you to run a 'command line' command (i.e. run a program).

On Windows XP: How to create a user with read access to only one certain directory?

Let me state first: I know that any user that wants to run a program (or even log in), has to have access to (probably at least) the Windows system directories and the shared libraries in %ProgramFiles%, but I'd like to be able to access Skype, for example, by running it with an unprivileged user and make sure that it can't access any unnecessary files.
I fear that the only way to do this would be to identify all of the gazillion directories where I store files that I don't want this user to access and then create a new user group that can access these directories, or run Skype and Azureus in a VM.
Is there a better way?
Normally, accounts are members of the Users group at least, which does have access to many things. You could make the account a member of no groups, or the Guests group which is very restrictive.
The real issue is that the program's token (an internal security object that keeps track of what security identities a running process has) will contain the Everyone and Authenticated Users groups, which also have read access to lots of stuff. There is no way to create an account without those groups. You could remove the access that Everyone and Authenticated Users groups have to most everything, but it would be a lot of work to track all those down.
I would say that creating a standard user or guest access account for untrusted programs would be plenty secure enough. To support self-updates and to keep related files in the same place, I suggest you install those programs directly in the profile of the user account they will be running as, e.g. C:\Documents and Settings\skype\Program Files\Skype
If you want to get really fancy, you can use a restricted token to either make the Everyone, Authenticated Users, etc. groups deny only (so they can't grant any access) or create a Restricted SID list. This will be difficult to implement because there are global objects that programs will expect to access that the Everyone group has access to, which is normally a safe choice.
See CreateRestrictedToken Function.
There is also an open-source command line program I created a program for creating restricted tokens and job objects on the fly for that purpose: UlimitNT
Maybe sudown is a solution. It's a sudo-similar (as known from Linux) approach to running as unprivileged user, but having the possibility to promote to an administrative account (with password) when needed.
I suppose you could lock down the machine so the user can solely log on, not even start skype with his rights, but start skype by "run as" with sudown.
Besides using a VM you could look into using a Sandbox. Look at Sandboxie fox an example.
simply use acl apis (samples in msdn)

Resources